7 ms·

Fwiw a branch isn't a named sequence of commits, it's just a label that points to a single commit. It's exactly the same as a tag except that git moves it when

Fwiw a branch isn't a named sequence of commits, it's just a label that points to a single commit. It's exactly the same as a tag except that git moves it when you make a new commit. Mercurial calls these bookmarks which IMO is a much better name because it works exactly like real bookmarks (in books, not browsers). A git branch feels a little bit like a branch of a tree because each commit points to their parent. Therefore, you don't need to track the entire sequence of commits in the branch but just the commit at the tip. I think if they'd had named only this concept better, Git would've been way easier to grok. I wouldn't usually nitpick like this but given that the entire point of this article is it matters to get the basic concepts right, I figured the author might want to get this basic concept right.

lisper 4y ago
> each commit points to their parent Potentially more than one.
- tomjakubowski 4y ago
  just to spell it out fully for dear reader: that's how merge commits work.
  - Anunayj 4y ago
    and Just for fun, sometimes it can be as big as 66, meet Cthulhu merge [1] 1. https://lkml.org/lkml/2014/1/21/361 https://lkml.org/lkml/2014/1/21/361
    - hinkley 4y ago
      Linus doesn't appear to be particularly enthusiastic about this strategy. Humans really do handle treating changes as a sequence. I wonder if this was really necessary or could have been serialized.
      - HWR_14 4y ago
        Mercurial, by the spec, only allows two parents to force merges like that into a sequence.
    - wdfx 4y ago
      And when you are playing around with git to try this strategy and it's not allowed you get the wonderful error message "should not be doing an octopus". (IIRC, from some version of git from about 6 years ago)
    - chrismorgan 4y ago
      There are realistic uses for more even than that. I’ve worked with a system of pre-production deploying where you labelled your PR/MR/whatever-you-call-it “include-in-beta” or whatever, and the beta branch would be reconstructed to be an octopus merge of the production branch and all include-in-beta heads. (When I came to the process, it was doing sequential merges, which got very slow when you had a whole bunch of work backing up that you couldn’t deploy to production just yet, so I turned it into a single octopus merge which was much, much faster, only falling back to sequential merges if the octopus merge failed, so that it could point out which MR conflicted. I don’t remember how high the numbers ever got, but I think it went beyond 66 at times, even with only a couple of dozen developers.) Graph log visualisation was certainly fairly difficult to make much of, but it wasn’t generally intended to be made much of, since it was basically a deployment implementation detail.
jsmith45 4y ago
This is exactly the point the author plans to address under "Branches are fictitious", in the outline at the top.
- skrebbel 4y ago
  Sure but then why do they describe the term wrong in the first paragraph? That's just adding to the confusion they intend to fight. I'm not sure the author is reading this, but think it's worth rewording.
  - mjd 4y ago
    I'm reading it and I think I got it right. The Git community, the Git documentation, and the Git tools all refer to "branches", and I think what they mean when they talk about "branches" is much closer to what I described than to what you did. For example, consider this very ordinary-sounding phrase that I just picked out of the git-rebase man page: > If the upstream branch already contains a change you have made … I don't think your account can explain what is meant by this. In any case, I didn't make the choice casually, thoughtlessly, or from ignorance.
    - layer8 4y ago
      But what’s the precise rule defining what constitutes the commits of a branch, after you reach a merge point? Does the branch end there? If not, which parent of the merge does it go? It’s not clear a priori.
      - edflsafoiewq 4y ago
        I think it goes to all the parents, ie. a branch denote not a linear sequence of commits, but an entire sub-DAG.
      - mjd 4y ago
        I don't think there is a precise rule. because the exact meaning depends on the context. In part 3 of the series, in the section about "branches are fictitious", that's what I will say. The talk has an abbreviated version: https://perl.plover.com/classes/git-tips/samples/slide018.html https://perl.plover.com/classes/git-tips/samples/slide018.ht... It's an illustration of just one example of this: If we rebase "branch X" onto commit B, we rebase only the three green commits. But if we rebase it onto C, we consider X to contain the two dark blue commits also. Are the dark blue commits part of branch X? It depends on what you're trying to communicate.
HWR_14 4y ago
Am I the only one sad that Git beat out Mercurial as the industry standard? And am I also the only one who still knows how to do things in Mercurial but not how to take the corresponding action in Git? I mean, they're things I haven't had a reason to do in years, but it has some psychological cost to feel like I'm using a system I'm worse at.
- cryptonector 4y ago
  I'm not sad. Mercurial is opinionated. It's had to adopt the Git way slowly, grudgingly.
- brianwawok 4y ago
  I was on the team of a large org doing a POC between the two. Merc did some stuff better, git did more. I am glad git won out overall. I think the only feature Merc had that I cared about was tracking folders as objects.
  - fero14041 4y ago
    Mike Bayer, creator of SQLAlchemy ORM in Python, wrote about migrating its repository from Mercurial to Git, in 2013: https://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrated-to-git/ https://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrat... He had some IMHO strong points in favor of Git itself VS Hg, besides GitHub and its huge userbase, which personally convinced me to switch.
  - HWR_14 4y ago
    Mind if I ask what Git did better? The main selling point for the difference between them was the Linus, Linux and then the whole community chose Git. The only big difference I recall Git winning on was in third party tooling and Git supporting more than two parents merging.
    - toyg 4y ago
      Git wasn't really winning until GitHub emerged. The game was still open at that point. Once GH had resoundingly beat the competition for "social coding" (like bitbucket and sourceforge), though, it was all over.
deleted 4y ago
[deleted]
pdonis 4y ago
> each commit points to their parent. Therefore, you don't need to track the entire sequence of commits in the branch but just the commit at the tip. This is not entirely true, because it is perfectly possible to create commit graphs in git in which there is not a single well-defined branch for some commits. So just knowing the branch labels at each tip is not sufficient to assign a single well-defined branch to every commit in the graph. Mercurial branches don't work like this: they are actually stored as part of each commit, so even with ambiguous commit graphs each commit still has a well-defined branch.
- TacticalCoder 4y ago
  Yeah I much preferred Mercurial from that standpoint. And branches there were correctly named branch. But you kinda, sorta, can get "what should have been called branches but don't exist in Git" by using named tags when you "start a branch" (a real branch I mean, not a Git "branch"). > Mercurial branches don't work like this: they are actually stored as part of each commit, so even with ambiguous commit graphs each commit still has a well-defined branch. I wonder which operation would not be possible with Git had Git gone that way. And hence I wonder too what's that operation that Git can do and that Mercurial can't. Honestly switching from Mercurial to Git this weird "branch that aren't branch at all" was the single most WTF feature of Git.
  - shikoba 4y ago
    > branch that aren't branch at all What do you mean? Git branches are branches. What is a branch for you? And why git branches aren't?
    - pdonis 4y ago
      Read the post of mine that TacticalCoder was responding to.
      - shikoba 4y ago
        I already read it. It's not clear to me.
kjeetgill 4y ago
I think bookmarks are a fine name but I don't really see quibble about branches, which I think are an even better name, but I know it's because I'm seeing it with my git goggles on. Can you elaborate on what you think branches are a better reference to? What operations or concepts are better expressed in terms of them? I think I'm at the edge of an epiphany here ... but I'm not quite groking it yet.
- emmelaich 4y ago
  The issue is the "named" bit of the definition, more precisely "named sequence". A commit is as much a branch as a head of a linked list is both a node and a list. I think 'branch' is fine.
  - kovac 4y ago
    Nice analogy there comparing it to a linked list.
omegalulw 4y ago
> a branch isn't a named sequence of commits, it's just a label that points to a single commit. True, but in the past majority of cases parent commits in the branch (commits from leaf to the last ancestor that has only one child) would be semantically very related so this understanding is not that bad (so long as you remember a branch is a commit for git operations).

lisper 4y ago

> each commit points to their parent Potentially more than one.

tomjakubowski 4y ago
just to spell it out fully for dear reader: that's how merge commits work.
- Anunayj 4y ago
  and Just for fun, sometimes it can be as big as 66, meet Cthulhu merge [1] 1. https://lkml.org/lkml/2014/1/21/361 https://lkml.org/lkml/2014/1/21/361
  - hinkley 4y ago
    Linus doesn't appear to be particularly enthusiastic about this strategy. Humans really do handle treating changes as a sequence. I wonder if this was really necessary or could have been serialized.
    - HWR_14 4y ago
      Mercurial, by the spec, only allows two parents to force merges like that into a sequence.
  - wdfx 4y ago
    And when you are playing around with git to try this strategy and it's not allowed you get the wonderful error message "should not be doing an octopus". (IIRC, from some version of git from about 6 years ago)
  - chrismorgan 4y ago
    There are realistic uses for more even than that. I’ve worked with a system of pre-production deploying where you labelled your PR/MR/whatever-you-call-it “include-in-beta” or whatever, and the beta branch would be reconstructed to be an octopus merge of the production branch and all include-in-beta heads. (When I came to the process, it was doing sequential merges, which got very slow when you had a whole bunch of work backing up that you couldn’t deploy to production just yet, so I turned it into a single octopus merge which was much, much faster, only falling back to sequential merges if the octopus merge failed, so that it could point out which MR conflicted. I don’t remember how high the numbers ever got, but I think it went beyond 66 at times, even with only a couple of dozen developers.) Graph log visualisation was certainly fairly difficult to make much of, but it wasn’t generally intended to be made much of, since it was basically a deployment implementation detail.

jsmith45 4y ago

This is exactly the point the author plans to address under "Branches are fictitious", in the outline at the top.

skrebbel 4y ago
Sure but then why do they describe the term wrong in the first paragraph? That's just adding to the confusion they intend to fight. I'm not sure the author is reading this, but think it's worth rewording.
- mjd 4y ago
  I'm reading it and I think I got it right. The Git community, the Git documentation, and the Git tools all refer to "branches", and I think what they mean when they talk about "branches" is much closer to what I described than to what you did. For example, consider this very ordinary-sounding phrase that I just picked out of the git-rebase man page: > If the upstream branch already contains a change you have made … I don't think your account can explain what is meant by this. In any case, I didn't make the choice casually, thoughtlessly, or from ignorance.
  - layer8 4y ago
    But what’s the precise rule defining what constitutes the commits of a branch, after you reach a merge point? Does the branch end there? If not, which parent of the merge does it go? It’s not clear a priori.
    - edflsafoiewq 4y ago
      I think it goes to all the parents, ie. a branch denote not a linear sequence of commits, but an entire sub-DAG.
    - mjd 4y ago
      I don't think there is a precise rule. because the exact meaning depends on the context. In part 3 of the series, in the section about "branches are fictitious", that's what I will say. The talk has an abbreviated version: https://perl.plover.com/classes/git-tips/samples/slide018.html https://perl.plover.com/classes/git-tips/samples/slide018.ht... It's an illustration of just one example of this: If we rebase "branch X" onto commit B, we rebase only the three green commits. But if we rebase it onto C, we consider X to contain the two dark blue commits also. Are the dark blue commits part of branch X? It depends on what you're trying to communicate.

HWR_14 4y ago

Am I the only one sad that Git beat out Mercurial as the industry standard? And am I also the only one who still knows how to do things in Mercurial but not how to take the corresponding action in Git? I mean, they're things I haven't had a reason to do in years, but it has some psychological cost to feel like I'm using a system I'm worse at.

cryptonector 4y ago
I'm not sad. Mercurial is opinionated. It's had to adopt the Git way slowly, grudgingly.
brianwawok 4y ago
I was on the team of a large org doing a POC between the two. Merc did some stuff better, git did more. I am glad git won out overall. I think the only feature Merc had that I cared about was tracking folders as objects.
- fero14041 4y ago
  Mike Bayer, creator of SQLAlchemy ORM in Python, wrote about migrating its repository from Mercurial to Git, in 2013: https://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrated-to-git/ https://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrat... He had some IMHO strong points in favor of Git itself VS Hg, besides GitHub and its huge userbase, which personally convinced me to switch.
- HWR_14 4y ago
  Mind if I ask what Git did better? The main selling point for the difference between them was the Linus, Linux and then the whole community chose Git. The only big difference I recall Git winning on was in third party tooling and Git supporting more than two parents merging.
  - toyg 4y ago
    Git wasn't really winning until GitHub emerged. The game was still open at that point. Once GH had resoundingly beat the competition for "social coding" (like bitbucket and sourceforge), though, it was all over.

deleted 4y ago

[deleted]

pdonis 4y ago

> each commit points to their parent. Therefore, you don't need to track the entire sequence of commits in the branch but just the commit at the tip. This is not entirely true, because it is perfectly possible to create commit graphs in git in which there is not a single well-defined branch for some commits. So just knowing the branch labels at each tip is not sufficient to assign a single well-defined branch to every commit in the graph. Mercurial branches don't work like this: they are actually stored as part of each commit, so even with ambiguous commit graphs each commit still has a well-defined branch.

TacticalCoder 4y ago
Yeah I much preferred Mercurial from that standpoint. And branches there were correctly named branch. But you kinda, sorta, can get "what should have been called branches but don't exist in Git" by using named tags when you "start a branch" (a real branch I mean, not a Git "branch"). > Mercurial branches don't work like this: they are actually stored as part of each commit, so even with ambiguous commit graphs each commit still has a well-defined branch. I wonder which operation would not be possible with Git had Git gone that way. And hence I wonder too what's that operation that Git can do and that Mercurial can't. Honestly switching from Mercurial to Git this weird "branch that aren't branch at all" was the single most WTF feature of Git.
- shikoba 4y ago
  > branch that aren't branch at all What do you mean? Git branches are branches. What is a branch for you? And why git branches aren't?
  - pdonis 4y ago
    Read the post of mine that TacticalCoder was responding to.
    - shikoba 4y ago
      I already read it. It's not clear to me.

kjeetgill 4y ago

I think bookmarks are a fine name but I don't really see quibble about branches, which I think are an even better name, but I know it's because I'm seeing it with my git goggles on. Can you elaborate on what you think branches are a better reference to? What operations or concepts are better expressed in terms of them? I think I'm at the edge of an epiphany here ... but I'm not quite groking it yet.

emmelaich 4y ago
The issue is the "named" bit of the definition, more precisely "named sequence". A commit is as much a branch as a head of a linked list is both a node and a list. I think 'branch' is fine.
- kovac 4y ago
  Nice analogy there comparing it to a linked list.

omegalulw 4y ago

> a branch isn't a named sequence of commits, it's just a label that points to a single commit. True, but in the past majority of cases parent commits in the branch (commits from leaf to the last ancestor that has only one child) would be semantically very related so this understanding is not that bad (so long as you remember a branch is a commit for git operations).