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.
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.
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.
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?
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.
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.
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.
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.
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.
31 comments
[ 5.0 ms ] story [ 73.0 ms ] threadFor instance, git add --patch can be done with hg record.
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.
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.
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?
Seriously, there's a project by Carl Worth to quite literally port the Mercurial book to Git. See http://cworth.org/hgbook-git/
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.
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.
and probably a few more
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?
I still say it's better to avoid that mess in the first place.
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.
Honestly, no offense meant, but I'm starting to wonder if Subversion is the Blub of source control systems.
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.