Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Hacker’s Guide to Git

wildlyinaccurate.com

Post reply on HN
Print view View original

91–100 of 120 posts

Re: A Hacker’s Guide to Git

#91

Post by Crito »

lloeki wrote: post #86

Every tutorial I read falls in two camps: 1. try to be helpful and simplify commands to the extreme, possibly resulting in an subverted (in both the actual and software sense) and damaging explanation (e.g git add) 2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand. Both equally fail at making people get git. Having explained…

Your "second camp" of tutorial works exceedingly well at getting other hackers to understand how git works. Git "clicked" when I learned the internals, teaching me about various porcelain commands and their flags without teaching me what git actually is did nothing for me.

The reason why so many people are keen on teaching git by teaching how it works is because that is how they learned git.

Re: A Hacker’s Guide to Git

#92

Post by gnoway »

mistermann wrote: post #32
jammycakes wrote: post #28

What disappoints me most about this, as well as almost every other Git tutorial that I've seen, is that it uses the command line almost exclusively. Even those tutorials that I've seen that do refer to GUI options pay lip service to them at best. This is a shame because I personally found GUI front ends for Git and Mercurial critical to understanding how they work in the first place, and in fact some tasks (such as a…

Sorry for a bit of a Hijack.....anyone care to comment on what is generally considered the best git GUI tool for Windows/Visual Studio?

A lot of our developers use GitExtensions and like it. I don't personally like or use it, so I am not sure why it is preferred.

Re: A Hacker’s Guide to Git

#93

Post by edanm »

dahart wrote: post #87
wldlyinaccurate wrote: post #35

Earlier quoted context omitted.

Author here. This is something I hear a lot, and I agree with it to a certain extent, but I purposely left out any mention of GUIs for a few reasons: 1. The guide is intended for people who want to take a look "under the hood". This is really difficult to do through GUIs, which tend to hide all of the implementation details. 2. As a child comment mentioned, even if I include GUIs in the guide, I can't possibly cover…

Jammycakes has a good point about certain features like interactive hunk selection being much easier to do using a GUI. But, git's natural habitat is the CLI, git was designed with and for the command line. There are no GUIs (yet) for git that expose git's full power, and I wish there were. And there are no GUIs (yet) that actually make git easier to understand (as opposed to making some known git workflows less labo…

"And there are no GUIs (yet) that actually make git easier to understand (as opposed to making some known git workflows less labor intensive) -- I also hope for this in the future, but it will require a more fundamental redesign of git's interface and terminology."

I heavily disagree with this.

When I started heavy use of git branches, being able to actually visualize what a branch is (e.g. just a pointed, as the article points out), being able to actually see the various branches merging into each other, it all just made my life easier.

When I used to explain git to our new employees, it was in the CLI, but I quickly moved to explaining it GUI-first because I could teach all the concepts much more quickly and they clearly understood better that way.

Re: A Hacker’s Guide to Git

#94

Post by Crito »

ams6110 wrote: post #26
egil wrote: post #24

Earlier quoted context omitted.

Git was originally created to manage the Linux kernel. It is indeed complex, but it has to be at that scale. Git might not be the best option for every project, but I find it quite easy to use at the trivial scale as well. (How do you beat 'git init' ? No repository setup or anything.)

I'm not so convinced. Other OSes manage with more "primitive" tools. OpenBSD still use CVS.

The BSDs use massive monolithic repos that would be difficult to move entirely over to git. Instead of putting separate projects in separate repos, they consider all of their different projects to actually be "one project". These ludicrously massive repos have no business being in git; they would need to restructure their projects to effectively migrate.

This is not a scheme that should be emulated. Compartmentalization/modularization is not only useful at the micro-level in code, all of it's benefits are available when applied at a project/organization level.

For another point of view, consider this page: https://wiki.freebsd.org/GitDrawbacks I think nearly everything on that page is misleaded/misleading, or flat out incorrect, and they failed to identify the technical limitations with git that would apply to them. Other viewpoints are nevertheless useful.

(Actually the BSDs use a handful of massive monolith repos, but that is just nitpicking/)

(Disclosure, I work at a company that uses git at a _much_ larger scale than the BSDs use CVS. Many many times larger than all the OpenBSD repos combined (http://www.openbsd.org/cvsync.html). The trick? We don't have a handful of repos for the company, we have a handful of repos for each team. Each project gets it's own repo. Our build systems, deployment systems, and dev environments are tooled for this. One of the things it even allows is different teams using different VCS, if you're on a team with a bunch of luddites you can still use SVN for your code, and you will be able to build against other code and other code will still be able to build against yours.)

Re: A Hacker’s Guide to Git

#95

Post by j_s »

stephengillie wrote: post #45

Where I work we just moved off Git to TFS. Our coders had a lot of trouble understanding Git, actually our whole company has had trouble with Git. We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command. We moved into TFS, and while we're working to get our DLLs to not be circularly referencing, we have an actually verifiable copy of our source code. Maybe…

Thank you for taking the time to share your anecdote, even if it is an unpopular one here. I hope Hacker News readers are understanding enough to recognize the need for buy-in from developers, and the necessity of a reasonable level of expertise when leading the switch to a distributed source control system. Sorry things didn't work out for your team; TFS branching and merging is so much more painful!

Re: A Hacker’s Guide to Git

#96

Post by alwillis »

collyw wrote: post #19
EinLama wrote: post #2

I'd recommend another guide. "Pro Git" by Scott Chacon is excellent and welcomes patches, source for the book and its translations are on GitHub http://www.git-scm.com/book

I appreciate that git is powerful, but should we really need to read a book just to get the best from a source control system? It seems overly complex to me at times (any time I do anything outside of my usual workflow). Version control only makes up a part of the whole development process, and plenty of coders out there manage without any at all.

Yes, Git is powerful, but it’s not the only open source, distributed version control system out there. Google’s comparison between Git and Mercurial is worth reading: https://code.google.com/p/support/wiki/DVCSAnalysis

Re: A Hacker’s Guide to Git

#97

Post by joeriel »

stephengillie wrote: post #67
eddiedunn wrote: post #55

Earlier quoted context omitted.

> We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command. What? 1) You can configure your repo so only select users may use destructive commands on certain branches. 2) It's a _distributed_ content versioning system. Even if someone wiped out the main, "central", repository, all users will have a full local copy, a backup in effect. Git has a horrible UI…

1. Some of this does look like ignorance on the part of my coworker who set up both. But why isn't that a default setting? Why give that permission to all users? 2. This is true only if other users keep local copies of the main repository, keep it updated, and don't mix it in with their code. You're making a lot of assumptions.

Your second statement shows a complete lack of understanding of VCS in general.

Re: A Hacker’s Guide to Git

#98

Post by skywhopper »

Crito wrote: post #91
lloeki wrote: post #86

Every tutorial I read falls in two camps: 1. try to be helpful and simplify commands to the extreme, possibly resulting in an subverted (in both the actual and software sense) and damaging explanation (e.g git add) 2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand. Both equally fail at making people get git. Having explained…

Your "second camp" of tutorial works exceedingly well at getting other hackers to understand how git works. Git "clicked" when I learned the internals, teaching me about various porcelain commands and their flags without teaching me what git actually is did nothing for me. The reason why so many people are keen on teaching git by teaching how it works is because that is how they learned git.

Agreed. I sorta knew the details before, but this article laid out the meaning of refs, trees, branches, and tags in a way that finally clicked for me. Would it have helped me get started with git back in the day when I only grokked Subversion? I can't say for sure now, but reading it today it clicked in a major way.

Re: A Hacker’s Guide to Git

#99

Post by tieTYT »

I've got the right level of understanding of Git to grok this article. I really liked how you talked about cherry picking before you talked about rebaseing. I'd like to request you include a section on why/when you need the rebase --onto argument.
Post reply on HN