4 ms·
> Git's ... ability to switch branches really easily within one checkout (rather than encouraging the use of multiple working directories) As a heavy Mercurial
by quietbritishjim 8y ago
> Git's ... ability to switch branches really easily within one checkout (rather than encouraging the use of multiple working directories)
As a heavy Mercurial user, but only for the last couple of years, I'm confused by this one. You can just as easily switch between branches (in the Mercurial sense) and bookmarks (which are Mercurial's name for Git-style branches). How did that used to be different?
In fact one of the nice thing about Mercurial is that you can easily switch to any commit and you don't need to choose between a hard reset and a detached head, because you can always make a commit anywhere (multiple heads for the same branch) and it will never get garbage collected (a foreign concept in Mercurial). Mostly this is good because you simply never need to understand what these concepts mean, which it turns out are not fundamental to DVCSs. But also this makes a neater alternative to stash (although stash is also available): just commit your half-finished changes, mark the revision "secret" (which means it won't be included in any push), then switch to another revision. You can always strip or rebase the revision later, so long as you haven't pushed it (admittedly these actions do require extensions, but they're included with all Mercurial installations).
- ygra 8y agoOur workflow at work (with Mercurial) revolves heavily around multiple heads for a single branch and relating the commits to a JIRA issue is done by simply putting the issue number in the commit message. So we have (unnamed) feature branches and also no bookmarks for them. You just start from the latest release tag and create new commits. No need to think of a name for the feature branch, or telling the reviewer or issue tracker which bookmark belongs to that issue. This might be mainly habit and familiarity with a different tool by now, but to me it's simpler than equivalent Git workflows as there's less ceremony involved to start working and there's no fear around accidentally losing commits because they don't belong to a branch (I kinda hate having to go into the Git reflog to find commits that are temporarily lost because they don't belong to a branch).
- bmurphy1976 8y agoWell that is just about the strangest workflow I've heard of. It sure seems like you are throwing away a lot of the power of the tools to do things manually. Honestly, I don't see the point. I've used Mercurial from the very beginning, the branches are great and bookmarks are fine. I see no reason why you wouldn't use them.
- ygra 8y agoWe use both, just not in the way a typical git workflow would use feature branches. Basically those are all anonymous heads on the same branch for us; a workflow that is probably as alien to git users as naming each and every head is to Mercurial users.
- krupan 8y agoBookmarks are a relatively recent addition to mercurial, but as you point out you could always easily switch to any commit. It's just that people didn't understand how to work that way early on. The recommended flow of mercurial in the early days was to have a clone per anonymous branch, or to use named branches, if I remember correctly. We as a community of developers have learned a lot about the power of DVCS since git and mercurial got started. I'd say even the developers of those two tools have learned a lot since then.
- ksec 8y ago>We as a community of developers have learned a lot about the power of DVCS since git and mercurial got started. I'd say even the developers of those two tools have learned a lot since then. So are we going to have something better than both hg and Git? There hasn't been any new DVCS for a long time.