3 ms·

> You simply commit a new changeset based on the desired parent. The branch would be created implicitly by having a revision with two or more children. And the

> You simply commit a new changeset based on the desired parent. The branch would be created implicitly by having a revision with two or more children. And then, how do you later track these commits? How do you change or merge branches if they have no names? Do you go around remembering revision-IDs? I'm not trying to be judgemental and say this is wrong or anything, but I'm curious how this works out in practice.

rbehrends 12y ago
First, let me note that neither Git nor Mercurial is my preferred VCS, so you'd ideally want to ask somebody else about common practices (my own preferences are naturally influenced by other VCSs). My own preferred approach is to use hg share, which allows me to have multiple checkouts of the same repository, each with a different current revision (HEAD in Git parlance). This is because when I'm doing some local branching, I generally like to have two different sets of files to work with (so as not having to rebuild when switching back and forth, being able to easily run side-by-side comparisons, etc.). This is sort of like Git's git-new-workdir, except that git-new-workdir isn't safe; it is also the default mode of operation of pretty much any DVCS other than Git and Mercurial. This, I note, is not necessarily what the majority of Mercurial users do -- especially since this feature first has to be switched on --, but is one of the major reasons why, if I have to pick either Git or Mercurial, I'll generally go with Mercurial. Multiple checkouts are simply too important a feature for me to want to deal with Git's workarounds; Mercurial's support of them is imperfect, but still better than what Git has. More commonly, in Mercurial you will simply not need to name temporary branches. You will have named branches for your major features etc., and you can use hg heads -r <branch> to list the 1-3 heads you may at any time have per major branch. This makes naming the heads sort of superfluous for typical development. Also, if you have only two heads in a branch, hg merge and hg rebase will automatically pick the other head to merge/rebase against. Alternatively, you can use bookmarks. Bookmarks are essentially like Git branches in that they are pointers to commits. Finally, there's also nothing inherently wrong with simply using named branches, even for temporary work. It's up to you or your organization whether you want persistent or temporary names for temporary work.

rbehrends 12y ago

First, let me note that neither Git nor Mercurial is my preferred VCS, so you'd ideally want to ask somebody else about common practices (my own preferences are naturally influenced by other VCSs). My own preferred approach is to use hg share, which allows me to have multiple checkouts of the same repository, each with a different current revision (HEAD in Git parlance). This is because when I'm doing some local branching, I generally like to have two different sets of files to work with (so as not having to rebuild when switching back and forth, being able to easily run side-by-side comparisons, etc.). This is sort of like Git's git-new-workdir, except that git-new-workdir isn't safe; it is also the default mode of operation of pretty much any DVCS other than Git and Mercurial. This, I note, is not necessarily what the majority of Mercurial users do -- especially since this feature first has to be switched on --, but is one of the major reasons why, if I have to pick either Git or Mercurial, I'll generally go with Mercurial. Multiple checkouts are simply too important a feature for me to want to deal with Git's workarounds; Mercurial's support of them is imperfect, but still better than what Git has. More commonly, in Mercurial you will simply not need to name temporary branches. You will have named branches for your major features etc., and you can use hg heads -r <branch> to list the 1-3 heads you may at any time have per major branch. This makes naming the heads sort of superfluous for typical development. Also, if you have only two heads in a branch, hg merge and hg rebase will automatically pick the other head to merge/rebase against. Alternatively, you can use bookmarks. Bookmarks are essentially like Git branches in that they are pointers to commits. Finally, there's also nothing inherently wrong with simply using named branches, even for temporary work. It's up to you or your organization whether you want persistent or temporary names for temporary work.