The Thing About Git | Hacker News Reader

The Thing About Git

tomayko.com

86 pointsmqt31 comments

The more I use git, the more I like it. It's like a treasure trove of great features but still feels lightweight and close to the metal.

The article did a real good job of explaining what makes git different from the other popular VCS. I used to use git as a more flexible subversion, just bundling adds and commits. But after I had this concept figured out, I realized there is more to git than being distributed and more flexible than svn.

Interesting comparison of the tangled working copy problem, i'll have to dive into Git and see what all the fuss is about.

On a side note: Am I the only person that couldn't see the site in firefox on linux? It crashed my browser every time I opened it and I ended up using lynx to view the article.

Is there any GUI clients for GIT, or is it command line only? If there is no good visual client, then that would really suck. I use perforce at work, and its visual client is pretty decent, but I have a co-worker raving about git all the time, so I wanted to give it a try.

there are a few: giggle (developer.imendio.com/projects/giggle) git-gui (packaged with Git, at least on my distro) gitk (same as git-gui)

and probably a few more

I just started using git at the end of last week and after the initial bit of "Well it doesn't work like svn it's a pain" cursing I'm finally starting to get the hang of it. More tips like this are greatly appreciated as I am still very much a 4 commands git user.

I'm a big fan of Mercurial just for this reason. Mercurial offers most of the benefits of Git without the steep learning curve and poor documentation.

For instance, git add --patch can be done with hg record.

Hg misses some of the most key features. For example, most people find git's robust inline branching support to be an incredible boon for their workflow. Hg's implementation of this feature is poor by comparison.

Inline branching would be nice...

I think they do away with this for simplicity. Inline branching doesn't make that much conceptual sense a lot of the time. That said, I wish Hg had it.

Forgive me, because this is not an insult, but this "doesn't make conceptual sense" argument I hear so much is so much nonsense and excuses to me. Git supports multiple workflows and allows you to either directly resolve tainted-working-copy situations directly or avoid them.

By allowing for local branches you enable multiple parallel lines of development in one repository. It saves space, it saves effort, it saves time, and it's a cleaner way to organize your projects (all in one place rather than scatted across a directory listing). It also means you can evade the tainted-working-copy problem entirely by keeping short-lived, private, parallel branches of current feature development. Personally, I much prefer this mode of operation when I have the foresight to do it.

Incidentally, Mercurial does this now too. (for the archives)

I don't want to knock Mercurial; I think it's actually quite nice. However, I'm a little puzzled about why you think git has poor documentation. The User's Manual (http://www.kernel.org/pub/software/scm/git/docs/user-manual....) is quite readable and covers most common and many uncommon use cases. I've also never had trouble making sense of the man pages for the individual commands. They are dense, but they cover a whole slew of highly advanced functionality and have always seemed to me quite thorough.

Also, I'm not sure I agree git has a particularly steep learning curve. I know that in the pre-1.5 days, everyday usage required a lot more knowledge of the plumbing, but today, the high-level commands seem pretty straightforward to me. Sure, the index takes some getting used to (and a very nice tool it turns out to be, too), but is that really the only thing that makes you say that git has a steep learning curve?

Git and Mercurial are almost the same, when it comes to the command line interface!

Seriously, there's a project by Carl Worth to quite literally port the Mercurial book to Git. See http://cworth.org/hgbook-git/

okay, call me a luddite, but even after reading about this supposed solution to the tangled update problem, i'd never use it. too complicated for me.

So what do you do for version control?

Hardcopy printouts, marked with the date, in a shoebox under the bed... ;-)

we use svn at work, and i like it okay.

i suppose it has happened that i've got two sets of updates in progress that are tangled up somewhat, but i try to avoid such things, and usually succeed.

If you haven't already, watch Linus' Google tech talk about git.

I don't get it...

svn commit file1 file2 somemorestuff

Surely you just commit the files you want, and leave out the ones you're still working on :/

What am I missing?

You're missing that you may have made not one, but multiple substantive changes to file1, and you want to commit those changes separately.

Then you have a mess whatever revision control system you use. You have to manually decide which changes you want to commit in the file, and which you don't.

I still say it's better to avoid that mess in the first place.

Then you have a mess whatever revision control system you use.

True, but some make it much easier than others. Git is one of the easy ones.

I still say it's better to avoid that mess in the first place.

The article addressed this, and concluded as follows:

Here’s a general principle I would like my VCS to acknowledge: moving from the present point B to some desired point C should not require a change in behavior at point A in the past. More simply, the phrase: “you should have,” ought to set off alarm bells.

From whose perspective is that a mess? From the perspective of a source control system which cannot deal with how I choose to work?

Honestly, no offense meant, but I'm starting to wonder if Subversion is the Blub of source control systems.

For me it's a mess.

If I start to fix bug B on top of a half implemented feature A, I end up with a mess.

I don't understand why you would work that way, and don't understand what git solves that svn doesn't. You still have to untangle the mess yourself.

You've seriously never looked at a file and said to yourself, "These changes belong in two separate commits"?

This only works if you can guarantee that the changes are not intertwingled in the same code block. He is also taking a gamble that the result of his selection will actually parse/compile/pass unit tests (select as appropriate) - he has no way to be sure of this. He is pretty much going to have to do a "get" into another working copy to be able to check this out, so I don't think he is gaining quite as much as he believes.

This is great! This was the one big thing I knew how to do in darcs but not in Git.

Nice article, I learn something new about git everyday.

wow, i did not know about git add --patch. that seems very very powerful.

Sold.

Needless to say, Git is not for people who are bothered by lack of heavy structure. Sorta like dynamic languages.

Reply on news.ycombinator.com