9 ms·

Mercurial bookmarks are equivalent to git branches, but Mercurial branches have no equivalent in git. In Mercurial, branches give you a way to track the branche

Mercurial bookmarks are equivalent to git branches, but Mercurial branches have no equivalent in git. In Mercurial, branches give you a way to track the branches a commit is a part of which is good for long-running branches (I think of things like master, maybe a long running refactor or major feature branch) while bookmarks are great for the more normal workflow of small, focused, feature branching. Neither of those are designed to cover a gap in the core design, they are a _feature_ of the core design that git doesn't even have.

nickez 10y ago
Could you maybe specify better how this is implemented in hg so that I can understand why it would be better than: git branch --contains <commit>
- rcthompson 10y ago
  When you make the commit, hg records in the commit which branch you were on when you made it. It becomes a permanent part of the commit. Regardless of whether you later merge or even delete that branch, the association between that branch and that commit is still there. I personally don't understand the use case, and prefer git's way of handling things, but I don't rule out that other people find it useful.
  - aidenn0 10y ago
    One use case is given branch X, tell me what the branch looked like N commits in the past. Git cannot tell you this because all parent commits are equal. DVCS workflows tend towards lots of short-lived branches where it is less useful (which is why hg has bookmarks). It can also just simplify certain things. I can tell by checking if a commit is reachable from e.g. the v1.2 bugfix branch but not from master that the commit was post the 1.2.0 release to fix a bug. With hg branches you can just see that the commit was made the the v1.2 bugfix branch. This is very minor, but my experience with hg is that there are dozens of these minor niceties that are why a lot of hg users are still around despite git having clearly won the popularity contest.
    - justinlaster 10y ago
      >One use case is given branch X, tell me what the branch looked like N commits in the past. What am I not understanding here? You definitely can go N commits in the past on each branch, and even any commit. And if you rewrite history you can even use the reflog to really tell what the branch was like (as long as it hasn't been cleaned out).
      - stevelosh 10y ago
        ┌─────┐◀──────── master │Merge│◀──────── bugfix └▲───▲┘ │ │ │ │ │ ┌─┐ │ │B│ │ └▲┘ ┌─┐ │ │A│ │ └▲┘ │ └───┤ │ ┌────────┐ │Ancestor│ └────────┘ Which branch was commit `B` made on? What did the `bugfix` branch look like one commit ago?
        grzm 10y ago
        Nice use of Unicode! Do you have a tool to help you construct a diagram like this?
        deleted 10y ago
        [deleted]
        sampo 10y ago
        If you were in master when you merged bugfix in ("git merge bugfix"), then you can git cat-file -p master and see which commit, A or B, is listed as the first parent. This belongs to the master.
        justinlaster 10y ago
        > Which branch was commit `B` made on You can do some basic heuristics to figure it out, but I'm not sure what the point of knowing this is. >What did the `bugfix` branch look like one commit ago? `git checkout bugfix; git log bugfix^1`
      - zck 10y ago
justinlaster 10y ago
>branches give you a way to track the branches a commit is a part of which is good for long-running branches I think you have a slight misunderstanding on the differences between git and mercurial, as git absolutely allows you to do this. Mercurial tends to track this information in a way where it actually limits telling you what branches a commit is contained in. Git will tell you straight up which branches lead back to a commit (i.e., being contained in them). Mercurial tends to only give you immediate, direct ancestors, any kind of complicated history and Mercurial can't be bothered to actually to dive in and tell you what branches a commit is really apart of. That seems to be strangely counter-intuitive for "long running branches." Git doesn't need an equivalent of Mercurial branches and bookmarks, because git branches do everything both of those mercurial features do and more, in a far more lightweight and efficient manner contained in a clean, singular feature.
- babyrainbow 10y ago
  Mercurial records in every commit, that branch it was made. It is part of it's identity. That is what the parent is talking about. Git does not do this. Because git does not have this concept of named branches. In other words, Mercurial has feature branches, while git has developer branches. This gives much more possible workflows in case of Mercurial. >Mercurial tends to only give you immediate, direct ancestors, any kind of complicated history and Mercurial can't be bothered to actually to dive in and tell you what branches a commit is really apart of... http://stackoverflow.com/questions/7166011/mercurial-find-all-branches-where-commit-exists http://stackoverflow.com/questions/7166011/mercurial-find-al... Is that what you are talking about? Mercurial contains vastly more querying capabilities in the form of revsets. No such thing exists for Git. If you go head to head with git vs mercurial, git will loose pathetically.
  - justinlaster 10y ago
    >Git does not do this. Because git does not have this concept of named branches. It doesn't pre-bake the information in the commit, because it's entirely useless information to bake into a commit; and even in the case of Mercurial can paint the wrong picture about the nature of a commit given branches that it's on. >This gives much more possible workflows in case of Mercurial. That is the exact opposite of what it gives you. I'm not even sure how you possibly arrived at that conclusion. >Mercurial contains vastly more querying capabilities in the form of revsets. Git doesn't need a query language, because you can literally do everything revsets will give you with git log and then maybe some very elementary bash script knowledge. You are literally arguing that Mercurial having its own arbitrary DSL is somehow better than git being able to seamlessly use popular tooling with conventional command line syntax; which seems to be at odds with the whole "mercurial is easier to use." I take extreme issue with your claim that Mercurial has "vastly" more querying capabilities and then you not even give one measly example.
sampo 10y ago
> branches give you a way to track the branches a commit is a part of which is good for long-running branches (I think of things like master, maybe a long running refactor or major feature branch) If you always merge "from the right direction", you can follow the first parent line in git and reconstruct which parent is in the master branch (or in the "heavier" branch in general) and which isn't. In more complicated situations, Mercurial named branches (commit forever carries the branch name) can be helpful. But you can get pretty far with git, too.

nickez 10y ago

Could you maybe specify better how this is implemented in hg so that I can understand why it would be better than: git branch --contains <commit>

rcthompson 10y ago
When you make the commit, hg records in the commit which branch you were on when you made it. It becomes a permanent part of the commit. Regardless of whether you later merge or even delete that branch, the association between that branch and that commit is still there. I personally don't understand the use case, and prefer git's way of handling things, but I don't rule out that other people find it useful.
- aidenn0 10y ago
  One use case is given branch X, tell me what the branch looked like N commits in the past. Git cannot tell you this because all parent commits are equal. DVCS workflows tend towards lots of short-lived branches where it is less useful (which is why hg has bookmarks). It can also just simplify certain things. I can tell by checking if a commit is reachable from e.g. the v1.2 bugfix branch but not from master that the commit was post the 1.2.0 release to fix a bug. With hg branches you can just see that the commit was made the the v1.2 bugfix branch. This is very minor, but my experience with hg is that there are dozens of these minor niceties that are why a lot of hg users are still around despite git having clearly won the popularity contest.
  - justinlaster 10y ago
    >One use case is given branch X, tell me what the branch looked like N commits in the past. What am I not understanding here? You definitely can go N commits in the past on each branch, and even any commit. And if you rewrite history you can even use the reflog to really tell what the branch was like (as long as it hasn't been cleaned out).
    - stevelosh 10y ago
      ┌─────┐◀──────── master │Merge│◀──────── bugfix └▲───▲┘ │ │ │ │ │ ┌─┐ │ │B│ │ └▲┘ ┌─┐ │ │A│ │ └▲┘ │ └───┤ │ ┌────────┐ │Ancestor│ └────────┘ Which branch was commit `B` made on? What did the `bugfix` branch look like one commit ago?
      - grzm 10y ago
        Nice use of Unicode! Do you have a tool to help you construct a diagram like this?
        deleted 10y ago
        [deleted]
      - sampo 10y ago
        If you were in master when you merged bugfix in ("git merge bugfix"), then you can git cat-file -p master and see which commit, A or B, is listed as the first parent. This belongs to the master.
      - justinlaster 10y ago
        > Which branch was commit `B` made on You can do some basic heuristics to figure it out, but I'm not sure what the point of knowing this is. >What did the `bugfix` branch look like one commit ago? `git checkout bugfix; git log bugfix^1`
    - zck 10y ago

justinlaster 10y ago

>branches give you a way to track the branches a commit is a part of which is good for long-running branches I think you have a slight misunderstanding on the differences between git and mercurial, as git absolutely allows you to do this. Mercurial tends to track this information in a way where it actually limits telling you what branches a commit is contained in. Git will tell you straight up which branches lead back to a commit (i.e., being contained in them). Mercurial tends to only give you immediate, direct ancestors, any kind of complicated history and Mercurial can't be bothered to actually to dive in and tell you what branches a commit is really apart of. That seems to be strangely counter-intuitive for "long running branches." Git doesn't need an equivalent of Mercurial branches and bookmarks, because git branches do everything both of those mercurial features do and more, in a far more lightweight and efficient manner contained in a clean, singular feature.

babyrainbow 10y ago
Mercurial records in every commit, that branch it was made. It is part of it's identity. That is what the parent is talking about. Git does not do this. Because git does not have this concept of named branches. In other words, Mercurial has feature branches, while git has developer branches. This gives much more possible workflows in case of Mercurial. >Mercurial tends to only give you immediate, direct ancestors, any kind of complicated history and Mercurial can't be bothered to actually to dive in and tell you what branches a commit is really apart of... http://stackoverflow.com/questions/7166011/mercurial-find-all-branches-where-commit-exists http://stackoverflow.com/questions/7166011/mercurial-find-al... Is that what you are talking about? Mercurial contains vastly more querying capabilities in the form of revsets. No such thing exists for Git. If you go head to head with git vs mercurial, git will loose pathetically.
- justinlaster 10y ago
  >Git does not do this. Because git does not have this concept of named branches. It doesn't pre-bake the information in the commit, because it's entirely useless information to bake into a commit; and even in the case of Mercurial can paint the wrong picture about the nature of a commit given branches that it's on. >This gives much more possible workflows in case of Mercurial. That is the exact opposite of what it gives you. I'm not even sure how you possibly arrived at that conclusion. >Mercurial contains vastly more querying capabilities in the form of revsets. Git doesn't need a query language, because you can literally do everything revsets will give you with git log and then maybe some very elementary bash script knowledge. You are literally arguing that Mercurial having its own arbitrary DSL is somehow better than git being able to seamlessly use popular tooling with conventional command line syntax; which seems to be at odds with the whole "mercurial is easier to use." I take extreme issue with your claim that Mercurial has "vastly" more querying capabilities and then you not even give one measly example.

sampo 10y ago

> branches give you a way to track the branches a commit is a part of which is good for long-running branches (I think of things like master, maybe a long running refactor or major feature branch) If you always merge "from the right direction", you can follow the first parent line in git and reconstruct which parent is in the master branch (or in the "heavier" branch in general) and which isn't. In more complicated situations, Mercurial named branches (commit forever carries the branch name) can be helpful. But you can get pretty far with git, too.