4 ms·

Why do people like Mercurial branches? Was it revamped? I hate it when I used it. By all means, I prefer Git branches.

KwanEsq 3y ago
I mean you can't really compare them since git doesn't even _have_ branches as Mercurial understands them. git's branches would perhaps better be called twigs in comparison. git's lightweight branches better map to Mercurial's topics or bookmarks, though neither perfectly. And Mercurial has even lighter weight branches since you can just make a new head by committing without having to name anything, and it won't yell at you about a detached head like git will.
notPlancha 3y ago
Pypy described the following in the FAQ: > The difference between git branches and named branches is not that important in a repo with 10 branches (no matter how big). But in the case of PyPy, we have at the moment 1840 branches. Most are closed by now, of course. But we would really like to retain (both now and in the future) the ability to look at a commit from the past, and know in which branch it was made. Please make sure you understand the difference between the Git and the Mercurial branches to realize that this is not always possible with Git— we looked hard, and there is no built-in way to get this workflow. > Still not convinced? Consider this git repo with three commits: commit #2 with parent #1 and head of git branch “A”; commit #3 with also parent #1 but head of git branch “B”. When commit #1 was made, was it in the branch “A” or “B”? (It could also be yet another branch whose head was also moved forward, or even completely deleted.) In this post they say that "Github notes solves much of point (1): the difficulty of discovering provenance of commits, although not entirely"
- dgfitz 3y ago
  The question in your example seems odd to me. It can be interpreted as either 2 OR 3 unique branches depending on how you read it. There is either base branch A whose current head is commit #2 / branch B with head of commit #3. OR Commit #1 is branch “default” commit #2 is branch “A” with parent as commit #1 and commit is branch “B” with parent also as commit #1 Consider your same example with forking instead of branching, how would the issue be resolved?
  - Dylan16807 3y ago
    > It can be interpreted as either 2 OR 3 unique branches depending on how you read it. The question isn't how many branches, it's what branch the commit was on at the point in time it was created. That's not up to interpretation. It's information that was not recorded. > Consider your same example with forking instead of branching, how would the issue be resolved? Forked repositories don't have IDs, don't generally keep track of each other, and there's no way to even count them. So that's not solvable. But branches do have names, and you almost always make commits onto branches. We shouldn't give up on tracking branches just because tracking forks is hard.
jcranmer 3y ago
There are benefits to having branches be an inherent property of a commit as opposed to the Git model of a dynamic property of the graph. Suppose I have a branch A with three commits, and then I make another branch B on top of that with another few commits. The Git model essentially says that B consists of all commits that are an ancestor of B that aren't the ancestor of any other branch. But now I go and rebase A somewhere else--and as a result, B suddenly grew several extra commits on its branch because those commits are no longer on branch A. If I want to rebase B on the new A, well, those duplicated commits will cause me some amount of pain, pain that would go away if only git could remember that some of those commits are really just the old version of A.
- sampo 3y ago
  > If I want to rebase B on the new A, well, those duplicated commits will cause me some amount of pain Not really. Git will recognize commits that produce an identical diff and skip them. Your only pain will be that for each skipped commit, you will see a notification line in the output of your `git rebase`: warning: skipped previously applied commit <hash>
  - jcranmer 3y ago
    If I had a nasty rebase of A, then git isn't smart enough to figure out that the new A' commits are similar enough to the old commits to know to skip the old-A commits.
- Ferret7446 3y ago
  > There are benefits to having branches be an inherent property of a commit And drawbacks, naturally. Advanced branching/merging workflows become extremely painful if not impossible, which makes mercurial unusable as a "true" DVCS (where everyone maintains a fork of the code and people trade PRs/merges).
  - Dylan16807 3y ago
    Like what? How does it differ from an extra line on each commit message saying the branch name, and some options to parse it if desired? I definitely get annoyed sometimes when I have to put in extra effort to figure out which side of the tree is which.

I mean you can't really compare them since git doesn't even _have_ branches as Mercurial understands them. git's branches would perhaps better be called twigs in comparison. git's lightweight branches better map to Mercurial's topics or bookmarks, though neither perfectly. And Mercurial has even lighter weight branches since you can just make a new head by committing without having to name anything, and it won't yell at you about a detached head like git will.

notPlancha 3y ago

Pypy described the following in the FAQ: > The difference between git branches and named branches is not that important in a repo with 10 branches (no matter how big). But in the case of PyPy, we have at the moment 1840 branches. Most are closed by now, of course. But we would really like to retain (both now and in the future) the ability to look at a commit from the past, and know in which branch it was made. Please make sure you understand the difference between the Git and the Mercurial branches to realize that this is not always possible with Git— we looked hard, and there is no built-in way to get this workflow. > Still not convinced? Consider this git repo with three commits: commit #2 with parent #1 and head of git branch “A”; commit #3 with also parent #1 but head of git branch “B”. When commit #1 was made, was it in the branch “A” or “B”? (It could also be yet another branch whose head was also moved forward, or even completely deleted.) In this post they say that "Github notes solves much of point (1): the difficulty of discovering provenance of commits, although not entirely"

dgfitz 3y ago
The question in your example seems odd to me. It can be interpreted as either 2 OR 3 unique branches depending on how you read it. There is either base branch A whose current head is commit #2 / branch B with head of commit #3. OR Commit #1 is branch “default” commit #2 is branch “A” with parent as commit #1 and commit is branch “B” with parent also as commit #1 Consider your same example with forking instead of branching, how would the issue be resolved?
- Dylan16807 3y ago
  > It can be interpreted as either 2 OR 3 unique branches depending on how you read it. The question isn't how many branches, it's what branch the commit was on at the point in time it was created. That's not up to interpretation. It's information that was not recorded. > Consider your same example with forking instead of branching, how would the issue be resolved? Forked repositories don't have IDs, don't generally keep track of each other, and there's no way to even count them. So that's not solvable. But branches do have names, and you almost always make commits onto branches. We shouldn't give up on tracking branches just because tracking forks is hard.

jcranmer 3y ago

There are benefits to having branches be an inherent property of a commit as opposed to the Git model of a dynamic property of the graph. Suppose I have a branch A with three commits, and then I make another branch B on top of that with another few commits. The Git model essentially says that B consists of all commits that are an ancestor of B that aren't the ancestor of any other branch. But now I go and rebase A somewhere else--and as a result, B suddenly grew several extra commits on its branch because those commits are no longer on branch A. If I want to rebase B on the new A, well, those duplicated commits will cause me some amount of pain, pain that would go away if only git could remember that some of those commits are really just the old version of A.

sampo 3y ago
> If I want to rebase B on the new A, well, those duplicated commits will cause me some amount of pain Not really. Git will recognize commits that produce an identical diff and skip them. Your only pain will be that for each skipped commit, you will see a notification line in the output of your `git rebase`: warning: skipped previously applied commit <hash>
- jcranmer 3y ago
  If I had a nasty rebase of A, then git isn't smart enough to figure out that the new A' commits are similar enough to the old commits to know to skip the old-A commits.
Ferret7446 3y ago
> There are benefits to having branches be an inherent property of a commit And drawbacks, naturally. Advanced branching/merging workflows become extremely painful if not impossible, which makes mercurial unusable as a "true" DVCS (where everyone maintains a fork of the code and people trade PRs/merges).
- Dylan16807 3y ago
  Like what? How does it differ from an extra line on each commit message saying the branch name, and some options to parse it if desired? I definitely get annoyed sometimes when I have to put in extra effort to figure out which side of the tree is which.