Version control systems nowadays suffer from the problem that all new version control systems are created by groups of hackers working on projects so big and complex that the existing systems aren’t powerful enough for them. So you keep getting more and more powerful and complex systems. git is so complex that no one who isn’t a software developer can use it correctly.
I was tasked with moving a complex natural-language processing program for the NIH from, I think, SVCS, to git. After three days studying git man pages and trying to explain them to a group of linguists, I gave up and put everything under QVCS, and it was smooth sailing after that.
I was taught to use git within a few days of starting to become a professional programmer. I’m a dyed-in-the-wool fanboy. I probably have no perspective at all here. But whenever I’ve used Mercurial everything seems backwards. People start recommending that I do wacky-sounding things like making two clones of a repository just to do what I’d normally do with git branch/git checkout… Is there any way to track multiple heads without just making multiple checkouts all over your disk?
Also, I strongly suspect that people who have trouble with git are just having trouble visualizing the DAG in their heads. If you run gitk—all whenever you get confused, you can actually see the thing, and then there’s nothing to be confused about.
...Though I suppose the above might just translate to “I’m a visual thinker, and everyone should be more like me.”
Well, to me, git’s DAG model is 100% obvious, and gitk --all is helpful in exactly the way you state — but at the beginning it was still confusing which command used how would produce the effect on the DAG (and working tree and index...) I wanted. Similarly, the commands to configure and manipulate branches and remotes are not entirely obvious, especially if you’ve gotten off the beaten path and want to fix your config to be normal.
Is there any way to track multiple heads without just making multiple checkouts all over your disk?
Taboo “track” and “checkouts”. I don’t know what you mean by “track”, and Mercurial doesn’t have checkouts, as I understand the term. A clone isn’t “checked out” of anything. (This was actually the hardest part for me to wrap my head around, coming from Subversion and the central-repository model, but I’m wondering whether you’re talking about the same thing or not.)
If you simply mean you want more than one head or branch, you don’t need multiple clones. You can switch your working copy between named branches or heads with “hg up”, and list them with “hg heads”.
It’s true that people often suggest just using clones instead of named branches, but IMO this only makes sense for short-lived branches that are going to be folded in to something else. Mercurial works just fine with named branches and multiple heads. You can also use bookmarks to give local names to specific heads—a kind of locally-named branch whose name isn’t propagated to other repositories.
I strongly suspect that people who have trouble with git are just having trouble visualizing the DAG in their heads.
No, we just read the man pages and run screaming. It’s not the model of a change-based system that’s the problem, it’s the UI design (or lack thereof). ;-)
From an outsider’s perspective, git’s UI is to mercurial’s UI as Perl’s is to Python. And since I’ve programmed almost exclusively in Python for about 13 years now, guess which one looks more attractive to me?
(Note: this doesn’t have anything to do with Mercurial’s innards being written in Python; other DVCS’s have been written in Python and didn’t have the same orthogonality of design.)
I’m told git massively improved its interface in the last few years. I started using it mainly in 2010 after switching from bzr, and had little trouble understanding the system (in fact I found hg’s interface to be kind of weird). But there you go.
(Also, wrt
Taboo “track” and “checkouts”. I don’t know what you mean by “track”, and Mercurial doesn’t have checkouts, as I understand the term. A clone isn’t “checked out” of anything.
In git-land “checkout” means a working directory; by “multiple checkouts all over your disk” I assume MBlume means multiple clones of the repository.)
Git is new. It’s already gotten easier to use (I’m already too much of a newb to have ever used the Git of Yore, which supposedly you needed a CS PhD to use effectively), and the folks at GitHub in particular seem to be working hard at sanding down its rough edges.
This is quite ancient. git started as a solution to technical problem of high performance distributed version control. They got user interface into something reasonable only later.
It’s still not that great. The internal DAG model is quite clean and clear. The actual commands do not always map clearly to this model. One common failure is often hiding or doing implicit magic to the staging area. Another is that many commands are a mish-mash of “manipulate the DAG” and “common user operations”, where doing only one or the other would be much clearer. I really doubt that the user interface will get much better, because to do so they really need to throw out backward compatibility.
Hee. We still use subversion every day.
Version control systems nowadays suffer from the problem that all new version control systems are created by groups of hackers working on projects so big and complex that the existing systems aren’t powerful enough for them. So you keep getting more and more powerful and complex systems. git is so complex that no one who isn’t a software developer can use it correctly.
I was tasked with moving a complex natural-language processing program for the NIH from, I think, SVCS, to git. After three days studying git man pages and trying to explain them to a group of linguists, I gave up and put everything under QVCS, and it was smooth sailing after that.
Try mercurial. It’s got basically the same features, but is more comprehensible to human beings. There’s an excellent tutorial called hg init.
(And if you should happen to need to use other people’s stuff that’s in git, you can just use the git extension for mercurial.)
blinks
I was taught to use git within a few days of starting to become a professional programmer. I’m a dyed-in-the-wool fanboy. I probably have no perspective at all here. But whenever I’ve used Mercurial everything seems backwards. People start recommending that I do wacky-sounding things like making two clones of a repository just to do what I’d normally do with git branch/git checkout… Is there any way to track multiple heads without just making multiple checkouts all over your disk?
Also, I strongly suspect that people who have trouble with git are just having trouble visualizing the DAG in their heads. If you run gitk—all whenever you get confused, you can actually see the thing, and then there’s nothing to be confused about.
...Though I suppose the above might just translate to “I’m a visual thinker, and everyone should be more like me.”
Well, to me, git’s DAG model is 100% obvious, and
gitk --allis helpful in exactly the way you state — but at the beginning it was still confusing which command used how would produce the effect on the DAG (and working tree and index...) I wanted. Similarly, the commands to configure and manipulate branches and remotes are not entirely obvious, especially if you’ve gotten off the beaten path and want to fix your config to be normal.Taboo “track” and “checkouts”. I don’t know what you mean by “track”, and Mercurial doesn’t have checkouts, as I understand the term. A clone isn’t “checked out” of anything. (This was actually the hardest part for me to wrap my head around, coming from Subversion and the central-repository model, but I’m wondering whether you’re talking about the same thing or not.)
If you simply mean you want more than one head or branch, you don’t need multiple clones. You can switch your working copy between named branches or heads with “hg up”, and list them with “hg heads”.
It’s true that people often suggest just using clones instead of named branches, but IMO this only makes sense for short-lived branches that are going to be folded in to something else. Mercurial works just fine with named branches and multiple heads. You can also use bookmarks to give local names to specific heads—a kind of locally-named branch whose name isn’t propagated to other repositories.
No, we just read the man pages and run screaming. It’s not the model of a change-based system that’s the problem, it’s the UI design (or lack thereof). ;-)
From an outsider’s perspective, git’s UI is to mercurial’s UI as Perl’s is to Python. And since I’ve programmed almost exclusively in Python for about 13 years now, guess which one looks more attractive to me?
(Note: this doesn’t have anything to do with Mercurial’s innards being written in Python; other DVCS’s have been written in Python and didn’t have the same orthogonality of design.)
I’m told git massively improved its interface in the last few years. I started using it mainly in 2010 after switching from bzr, and had little trouble understanding the system (in fact I found hg’s interface to be kind of weird). But there you go.
(Also, wrt
In git-land “checkout” means a working directory; by “multiple checkouts all over your disk” I assume MBlume means multiple clones of the repository.)
Harsh!
Git is new. It’s already gotten easier to use (I’m already too much of a newb to have ever used the Git of Yore, which supposedly you needed a CS PhD to use effectively), and the folks at GitHub in particular seem to be working hard at sanding down its rough edges.
My experience with git was in 2006 or 2007.
This is quite ancient. git started as a solution to technical problem of high performance distributed version control. They got user interface into something reasonable only later.
It’s still not that great. The internal DAG model is quite clean and clear. The actual commands do not always map clearly to this model. One common failure is often hiding or doing implicit magic to the staging area. Another is that many commands are a mish-mash of “manipulate the DAG” and “common user operations”, where doing only one or the other would be much clearer. I really doubt that the user interface will get much better, because to do so they really need to throw out backward compatibility.
There are some problem with DAG, too, because you are supposed to store the information with little meta-information.
There are precedents of tools wrapping Git command-line interface, so that part possibly could be fixed. I frankly do not know why nobody does it.