5 ms·

For Mercurial, you create a new local branch by committing at a point that's not a tip (or not HEAD, if there's just a single branch). By default, it doesn't h

For Mercurial, you create a new local branch by committing at a point that's not a tip (or not HEAD, if there's just a single branch). By default, it doesn't have a special name (like a git branch does). You can give it a name via "hg bookmark". The feature set is honestly fairly similar, it's just different in the way it is presented. In git you go into a "detached HEAD" and have to explicitly name a branch or commits will get lost. In hg you commit and it creates a new tip, but it doesn't have a name unless you explicitly name it via bookmark.

josteink 12y ago
> In git you go into a "detached HEAD" and have to explicitly name a branch or commits will get lost. Maybe I'm missing something, but this seems like a fairly academical scenario. When would you checkout a specific commit, keep working, keep committing, but not attach it to a name or a branch? How is "67846237864237846" a nicer reference than "bugfix" or whatever? To me this seems like people using git in a way it's specifically designed not to support and then go complaining when things go wrong.
- imakesnowflakes 12y ago
  >When would you checkout a specific commit, keep working, keep committing, but not attach it to a name or a branch? How is "67846237864237846" a nicer reference than "bugfix" or whatever? You enter a commit message when you make a commit, right? So I am not sure I see your point..
  - josteink 12y ago
    I don't think you understand my dilemma. Let me try to clear it up with an example. Let's say you have the following history: - Commit 1 -> Commit 2 -> Commit 3 (master/default) - current branch Now Commit 3 is the HEAD of your current branch (master, trunk, default, whatever). The way I understand your "problem" is if you want to create a new branch based on an older, non-HEAD commit. For instance you checkout the current branch on based on the state of the branch as per "Commit 2", and make a new Commit "Commit 4". This creates a new implicit branch: - Commit 1 -> Commit 2 +-> Commit 3 (master/default) +-> Commit 4 (implicit branch) - new current branch Now you have two branches. How do you switch between them? How do you operate on those branches? Do you cycle them? Do you have to remember the last commit-message of a branch to find it again? To be absolutely clear: What I'm curious about is how do you relate to and navigate between branches when they are all anonymous? What mechanisms do you have to aid identification?
    - imakesnowflakes 12y ago
      Anonymous heads are often short lived. You either merge them right away (Making them not a head), or bookmark it (Making them not anonymous) so that you can come back to it later. But say, you forget to merge it or didn't bookmark it, Mercurial does not hide the revision from you. The hg log will list it along with all the other commits. Even easier is to use the hg heads command, which will show all branch heads for you (Branch heads are change sets that have no descendants on the same branch), along with the commit summaries. You can use the commit summary to select the revision and use a revision id (You don't have to use the full length hash, instead you can use a 4 or 5 character prefix of the revision id) to switch to that commit.
      - josteink 12y ago
        I think it's funny how you say hg is much easier and git has a much more complex model, and I'm still struggling to understand all this. To me Git is clear and simple. It's a linked commit-graph, and branches and tags are just references to leaf nodes on the graph. That's all. That's the entire model. With hg you have local commit IDs, you have revsets, you have bookmarks, and then since you aren't forced to name a graph/branch you have to remember commit-IDs or who did what when to what file. Some commits show up on the commit-log, but you can't be sure if it's in the current branch. I'm totally confused as to what to use where and how I can be certain about what I'm working with. I'm not saying hg is bad per se, but looking at it from the outside it looks helluva more complex than Git. I think this all boils down to what you're used to. From the discussion in this thread here, I'm pretty certain I wont be trying mercurial anytime soon. It just seems too complex and confusing for me ;)
        imakesnowflakes 12y ago
        >To me Git is clear and simple. It's a linked commit-graph.. Same in Mercurial. But it lets you store a bit more meta data (Bookmarks, branch names, local revision numbers etc) which enables more powerful queries based on them. I am not sure that is a bad thing. But I can certainly understand why it appears complex to when presented with all these information at once. But trust me, when you are trying to make sense of what went wrong with a merge done by an in experienced co-worker, you want all the metadata you can get.. >and then since you aren't forced to name a graph/branch you have to remember commit-IDs or who did what when to what file. Some commits show up on the commit-log, but you can't be sure if it's in the current branch. Now you are talking FUD, no offence. >you have to remember commit-IDs... ??, I just told you how to manage such cases. Which part you didn't get? In Git you would have to dig up reflogs for the commit hash for a' DETACHED HEAD' that you just made, Right? >Some commits show up on the commit-log, but you can't be sure if it's in the current branch. Not sure what you mean by there or where you got that idea. Every commit you make will be displayed by the hg log, regardless of the branch it is on. If you want to filter log by a branch, there is a -b option accepts branch name as an argument, that you can use to limit the display to changesets in that branch only. >From the discussion in this thread here, I'm pretty certain I wont be trying mercurial anytime soon. It just seems too complex and confusing for me ;) If Mercurial was actually 'complex and confusing' it would have been dead a long time ago (Thanks to git). The simple fact that it survives (and even grows in popularity) despite git, IMHO is a sure sign of how simple/straightforward it actually is for common things. So do yourself a favor and try it sometimes. You just might like it.
- baq 12y ago
  this happens quite often in e.g. gerrit workflows, where you usually have to amend a change or if you want to take a look at somebody else's tree.
- Blackthorn 12y ago
  > Maybe I'm missing something, but this seems like a fairly academical scenario. No, you aren't missing anything. I merely used the example to illustrate the difference between the two VCS's. Like I said: they actually have a fairly equivalent set of features. The prime user-visible difference is in interface and implementation.

josteink 12y ago

> In git you go into a "detached HEAD" and have to explicitly name a branch or commits will get lost. Maybe I'm missing something, but this seems like a fairly academical scenario. When would you checkout a specific commit, keep working, keep committing, but not attach it to a name or a branch? How is "67846237864237846" a nicer reference than "bugfix" or whatever? To me this seems like people using git in a way it's specifically designed not to support and then go complaining when things go wrong.

imakesnowflakes 12y ago
>When would you checkout a specific commit, keep working, keep committing, but not attach it to a name or a branch? How is "67846237864237846" a nicer reference than "bugfix" or whatever? You enter a commit message when you make a commit, right? So I am not sure I see your point..
- josteink 12y ago
  I don't think you understand my dilemma. Let me try to clear it up with an example. Let's say you have the following history: - Commit 1 -> Commit 2 -> Commit 3 (master/default) - current branch Now Commit 3 is the HEAD of your current branch (master, trunk, default, whatever). The way I understand your "problem" is if you want to create a new branch based on an older, non-HEAD commit. For instance you checkout the current branch on based on the state of the branch as per "Commit 2", and make a new Commit "Commit 4". This creates a new implicit branch: - Commit 1 -> Commit 2 +-> Commit 3 (master/default) +-> Commit 4 (implicit branch) - new current branch Now you have two branches. How do you switch between them? How do you operate on those branches? Do you cycle them? Do you have to remember the last commit-message of a branch to find it again? To be absolutely clear: What I'm curious about is how do you relate to and navigate between branches when they are all anonymous? What mechanisms do you have to aid identification?
  - imakesnowflakes 12y ago
    Anonymous heads are often short lived. You either merge them right away (Making them not a head), or bookmark it (Making them not anonymous) so that you can come back to it later. But say, you forget to merge it or didn't bookmark it, Mercurial does not hide the revision from you. The hg log will list it along with all the other commits. Even easier is to use the hg heads command, which will show all branch heads for you (Branch heads are change sets that have no descendants on the same branch), along with the commit summaries. You can use the commit summary to select the revision and use a revision id (You don't have to use the full length hash, instead you can use a 4 or 5 character prefix of the revision id) to switch to that commit.
    - josteink 12y ago
      I think it's funny how you say hg is much easier and git has a much more complex model, and I'm still struggling to understand all this. To me Git is clear and simple. It's a linked commit-graph, and branches and tags are just references to leaf nodes on the graph. That's all. That's the entire model. With hg you have local commit IDs, you have revsets, you have bookmarks, and then since you aren't forced to name a graph/branch you have to remember commit-IDs or who did what when to what file. Some commits show up on the commit-log, but you can't be sure if it's in the current branch. I'm totally confused as to what to use where and how I can be certain about what I'm working with. I'm not saying hg is bad per se, but looking at it from the outside it looks helluva more complex than Git. I think this all boils down to what you're used to. From the discussion in this thread here, I'm pretty certain I wont be trying mercurial anytime soon. It just seems too complex and confusing for me ;)
      - imakesnowflakes 12y ago
        >To me Git is clear and simple. It's a linked commit-graph.. Same in Mercurial. But it lets you store a bit more meta data (Bookmarks, branch names, local revision numbers etc) which enables more powerful queries based on them. I am not sure that is a bad thing. But I can certainly understand why it appears complex to when presented with all these information at once. But trust me, when you are trying to make sense of what went wrong with a merge done by an in experienced co-worker, you want all the metadata you can get.. >and then since you aren't forced to name a graph/branch you have to remember commit-IDs or who did what when to what file. Some commits show up on the commit-log, but you can't be sure if it's in the current branch. Now you are talking FUD, no offence. >you have to remember commit-IDs... ??, I just told you how to manage such cases. Which part you didn't get? In Git you would have to dig up reflogs for the commit hash for a' DETACHED HEAD' that you just made, Right? >Some commits show up on the commit-log, but you can't be sure if it's in the current branch. Not sure what you mean by there or where you got that idea. Every commit you make will be displayed by the hg log, regardless of the branch it is on. If you want to filter log by a branch, there is a -b option accepts branch name as an argument, that you can use to limit the display to changesets in that branch only. >From the discussion in this thread here, I'm pretty certain I wont be trying mercurial anytime soon. It just seems too complex and confusing for me ;) If Mercurial was actually 'complex and confusing' it would have been dead a long time ago (Thanks to git). The simple fact that it survives (and even grows in popularity) despite git, IMHO is a sure sign of how simple/straightforward it actually is for common things. So do yourself a favor and try it sometimes. You just might like it.
baq 12y ago
this happens quite often in e.g. gerrit workflows, where you usually have to amend a change or if you want to take a look at somebody else's tree.
Blackthorn 12y ago
> Maybe I'm missing something, but this seems like a fairly academical scenario. No, you aren't missing anything. I merely used the example to illustrate the difference between the two VCS's. Like I said: they actually have a fairly equivalent set of features. The prime user-visible difference is in interface and implementation.