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.)
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!