5 ms·

Duh. I've never got the hang of git either, but I figure git is for those people who don't get enough mileage out of Mercurial because they have 42 megatons of

by sqrt17 16y ago

Duh. I've never got the hang of git either, but I figure git is for those people who don't get enough mileage out of Mercurial because they have 42 megatons of source code, or need git rebase, or just want to shock and awe their friends. But no need to hate git for that. No one's forcing you to use it. You don't like vim? Go ahead and use emacs/gedit/eclipse/perl. You don't like git? Use mercurial. Or subversion, if it makes you happier. Merging is always a pain with VCS, more so with DVCSs because they let you conveniently forget a bunch of patches in that repository copy on the USB stick in your back pocket . And these long mumblish version numbers are also going to stay - but they're not so bad when you use a graphical repository browser (hg view/hg_web/git-web/tortoise). And if you just need versioning for a couple .doc files: use Apache's mod_dav_svn and be done with it (i.e., you can mount it as a directory in Nautilus or the Mac finder and it just works). Even though I like all the fancy stuff in Hg, I started using it and never looked back because it's always been painless. (Oh, and you can work directly* on the repository, version history is mostly useless because it reflects weird program behaviour including temporary files, but you'll never get any conflicts unless you mess up really badly).

MikeTaylor 16y ago
"But no need to hate git for that. No one's forcing you to use it. You don't like vim? Go ahead and use emacs/gedit/eclipse/perl. You don't like git? Use mercurial" If only this were true. But it's not: if I work on a project where my colleagues keep the source in git, then I have to use git (whereas if they use vi, I am still at liberty to use emacs). That's the problem with CVSs -- they have a lot more inertia than most other tools because they are, by nature, shared by groups.
- ionfish 16y ago
  I presume you haven't come across Hg-Git, then. http://hg-git.github.com/ http://hg-git.github.com/
  - MikeTaylor 16y ago
    I've seen things like this. I would be very wary about trusting them with my precious source code, wouldn't you? However good they are, they're an additional layer in which (A) things can go wrong, and (B) you're insulated from the reality that you need to access to fix problems. I fear that Hg-Git would be one of those things that is an absolute delight for as long as it Just Works, then abruptly transitions into an absolute horror the moment something goes wrong.
    - fragmede 16y ago
      I suspect that many people feel the same about computers in general... I don't use Hg-Git, but I do use git-svn. Just like Hg-Git, I'm sure there are some caveats, but what finally got me to switch is that (at least for git-svn) it's a real live Git repo. Which means the code I write, my actual work, is all still there. The fix to my nightmare scenario? I do a fresh svn checkout to a new directory, and I do git checkout, I copy the files out, I do an svn commit of that version of files. Definitely far from ideal, to be sure, but in my mind, knowing that was the worse case scenario, put me quite at ease. (Sure I'd read about git svn dcommit, but knowing that did set my mind at ease.)
    - undees 16y ago
      I've been trusting my precious source code to Hg-Git for a while. The sort of "something goes wrong" moments have usually been fixable with a bit of grubbing around in Hg-Git's source. They've got themselves a pretty inviting code base, FWIW.
- arantius 16y ago
  > they have a lot more inertia than most other tools because they are, by nature, shared by groups. The term you're looking for is "network effect". http://en.wikipedia.org/wiki/Network_effect http://en.wikipedia.org/wiki/Network_effect
lars512 16y ago
Mercurial also has had rebase built-in for some time. For git users who have compared both, what features made you choose git over hg?
- codavid 16y ago
  I think git is much better than hg, but I think most complaints made in the post are fair. Git UI is truly awful. IMO, The two killer features of git are the index and content-based tracking. First the index makes dealing with OP situation much better once you understand it. For example, in hg (or any other VCS I know of), when you merge something and there is a conflict, every change is in your tree, and you don't know what's correctly merged from what's not through the VCS command. For example, hg diff will show you changes of both merged and unmerged stuff, but thanks to the index, git diff will show only the unmerged stuff. When you start fixing conflicts, when you add files with git add, those are not shown anymore with git diff (but are through git diff --cached). The index has a high learning curve, though. The other killer feature is code tracking: git blame -C -M is extremely powerful. It can tells you that which changes are coming from which file (through heuristics, so it also works for code converted to git, e.g. git-svn). I explained this in more details there http://cournape.wordpress.com/2009/05/12/why-people-should-stop-talking-about-git-speed/ http://cournape.wordpress.com/2009/05/12/why-people-should-s.... I think in the end, git is actually simpler than hg - that is, the UI is awful, but the underlying model is simple. For example, the branching model in git is simpler than hg. In hg, you have branch-through-clone, bookmark, branches created by hg branch ( http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...). This is maybe a matter of personal opinion, but I hate simple version numbers in DVCS (I changed from bzr to git because I wasted a lot of time with bzr so-called simple numbers). With DVCS, it is impossible to have a consistent version scheme (that is at some point, you will have several branches with the same simple version referring to different commits). One thing to understand is that you almost never need to use the raw id in git, because most commands understand a lot of different syntax such as HEAD^, HEAD~, branch names and tags. If I need to refer to a commit more than once, I use a tag for it. One think which git got wrong IMO is fast-forward when pulling: it means you lose branch information, and the history is hard to understand (it complicates life for bisect or continuous integration) - I change the pull command to make pull non fast forward by default in git. Going back to svn is insane if you ask me, at least for usual usage of source-code only (DVCS currently suck at assets management). I agree with the OP that branching is sometimes used too much by git users, but branching for release management, code reviews, etc... has saved me hours of work as a release manager on several middle-sized open source projects (through git-svn). Git got the low-level stuff right, but I think we have barely seen what's possible with DVCS. Bug-tracker integration, code-review integration, etc... are still in infancy.

by sqrt17 16y ago

MikeTaylor 16y ago

"But no need to hate git for that. No one's forcing you to use it. You don't like vim? Go ahead and use emacs/gedit/eclipse/perl. You don't like git? Use mercurial" If only this were true. But it's not: if I work on a project where my colleagues keep the source in git, then I have to use git (whereas if they use vi, I am still at liberty to use emacs). That's the problem with CVSs -- they have a lot more inertia than most other tools because they are, by nature, shared by groups.

ionfish 16y ago
I presume you haven't come across Hg-Git, then. http://hg-git.github.com/ http://hg-git.github.com/
- MikeTaylor 16y ago
  I've seen things like this. I would be very wary about trusting them with my precious source code, wouldn't you? However good they are, they're an additional layer in which (A) things can go wrong, and (B) you're insulated from the reality that you need to access to fix problems. I fear that Hg-Git would be one of those things that is an absolute delight for as long as it Just Works, then abruptly transitions into an absolute horror the moment something goes wrong.
  - fragmede 16y ago
    I suspect that many people feel the same about computers in general... I don't use Hg-Git, but I do use git-svn. Just like Hg-Git, I'm sure there are some caveats, but what finally got me to switch is that (at least for git-svn) it's a real live Git repo. Which means the code I write, my actual work, is all still there. The fix to my nightmare scenario? I do a fresh svn checkout to a new directory, and I do git checkout, I copy the files out, I do an svn commit of that version of files. Definitely far from ideal, to be sure, but in my mind, knowing that was the worse case scenario, put me quite at ease. (Sure I'd read about git svn dcommit, but knowing that did set my mind at ease.)
  - undees 16y ago
    I've been trusting my precious source code to Hg-Git for a while. The sort of "something goes wrong" moments have usually been fixable with a bit of grubbing around in Hg-Git's source. They've got themselves a pretty inviting code base, FWIW.
arantius 16y ago
> they have a lot more inertia than most other tools because they are, by nature, shared by groups. The term you're looking for is "network effect". http://en.wikipedia.org/wiki/Network_effect http://en.wikipedia.org/wiki/Network_effect

lars512 16y ago

Mercurial also has had rebase built-in for some time. For git users who have compared both, what features made you choose git over hg?

codavid 16y ago
I think git is much better than hg, but I think most complaints made in the post are fair. Git UI is truly awful. IMO, The two killer features of git are the index and content-based tracking. First the index makes dealing with OP situation much better once you understand it. For example, in hg (or any other VCS I know of), when you merge something and there is a conflict, every change is in your tree, and you don't know what's correctly merged from what's not through the VCS command. For example, hg diff will show you changes of both merged and unmerged stuff, but thanks to the index, git diff will show only the unmerged stuff. When you start fixing conflicts, when you add files with git add, those are not shown anymore with git diff (but are through git diff --cached). The index has a high learning curve, though. The other killer feature is code tracking: git blame -C -M is extremely powerful. It can tells you that which changes are coming from which file (through heuristics, so it also works for code converted to git, e.g. git-svn). I explained this in more details there http://cournape.wordpress.com/2009/05/12/why-people-should-stop-talking-about-git-speed/ http://cournape.wordpress.com/2009/05/12/why-people-should-s.... I think in the end, git is actually simpler than hg - that is, the UI is awful, but the underlying model is simple. For example, the branching model in git is simpler than hg. In hg, you have branch-through-clone, bookmark, branches created by hg branch ( http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...). This is maybe a matter of personal opinion, but I hate simple version numbers in DVCS (I changed from bzr to git because I wasted a lot of time with bzr so-called simple numbers). With DVCS, it is impossible to have a consistent version scheme (that is at some point, you will have several branches with the same simple version referring to different commits). One thing to understand is that you almost never need to use the raw id in git, because most commands understand a lot of different syntax such as HEAD^, HEAD~, branch names and tags. If I need to refer to a commit more than once, I use a tag for it. One think which git got wrong IMO is fast-forward when pulling: it means you lose branch information, and the history is hard to understand (it complicates life for bisect or continuous integration) - I change the pull command to make pull non fast forward by default in git. Going back to svn is insane if you ask me, at least for usual usage of source-code only (DVCS currently suck at assets management). I agree with the OP that branching is sometimes used too much by git users, but branching for release management, code reviews, etc... has saved me hours of work as a release manager on several middle-sized open source projects (through git-svn). Git got the low-level stuff right, but I think we have barely seen what's possible with DVCS. Bug-tracker integration, code-review integration, etc... are still in infancy.