4 ms·

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

by 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.
  - layer8 4y ago
    Right, and that’s what makes “branch” a vague notion in git. It’s not clear what exactly is meant with “branch x” when it’s not just about the labeled tip, and often enough no further clarification is given.
- shkkmo 4y ago
  Every commit contains an ordered list of it's parent commits. You could think of the 'main' history as being the chain of commits that are always the first ancestor to each other and this can be a use thing to display when generating a commit history. However, the history of a commit is always the entire tree of ancestors. This entire tree is the precise definition of what constitutes all the commits of a branch. Thus while I agree that it is not wrong to view a branch as a bookmark, I also think that attempts to nitpick the man page's use of the term fall flat here. "Commit contained in a branch" just means: "commit contained in the history of the commit the branch currently points to." and isn't ambiguous.
pierrebai 4y ago
The problem is that your rebuttal isn't one: you are not addressing any of the points made. And those points are important precisely because branches are not a range of commits which is why they are cumbersome to work with.
deleted 4y ago
[deleted]
skrebbel 4y ago
> In any case, I didn't make the choice casually, thoughtlessly, or from ignorance. Obviously, and if you got the idea that I thought you did then I apologize for that. Anyway, the git docs aren't exactly known for getting the nuances of its own concepts right, which adds to the general confusion. That said, I think I see your point now: it's the same as how a reference to a linked list is actually just the head of the linked list, but you still call it a list and not a head. I have to admit that maybe I didn't see the forest for the trees.

by mjd 4y ago

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.
- layer8 4y ago
  Right, and that’s what makes “branch” a vague notion in git. It’s not clear what exactly is meant with “branch x” when it’s not just about the labeled tip, and often enough no further clarification is given.
shkkmo 4y ago
Every commit contains an ordered list of it's parent commits. You could think of the 'main' history as being the chain of commits that are always the first ancestor to each other and this can be a use thing to display when generating a commit history. However, the history of a commit is always the entire tree of ancestors. This entire tree is the precise definition of what constitutes all the commits of a branch. Thus while I agree that it is not wrong to view a branch as a bookmark, I also think that attempts to nitpick the man page's use of the term fall flat here. "Commit contained in a branch" just means: "commit contained in the history of the commit the branch currently points to." and isn't ambiguous.

pierrebai 4y ago

The problem is that your rebuttal isn't one: you are not addressing any of the points made. And those points are important precisely because branches are not a range of commits which is why they are cumbersome to work with.

deleted 4y ago

[deleted]

skrebbel 4y ago

> In any case, I didn't make the choice casually, thoughtlessly, or from ignorance. Obviously, and if you got the idea that I thought you did then I apologize for that. Anyway, the git docs aren't exactly known for getting the nuances of its own concepts right, which adds to the general confusion. That said, I think I see your point now: it's the same as how a reference to a linked list is actually just the head of the linked list, but you still call it a list and not a head. I have to admit that maybe I didn't see the forest for the trees.