4 ms·

For years I was deeply annoyed by the terrible name “branch” for something that acts more like a bookmark (or “wandering tag” indeed!). And then I learned that

For years I was deeply annoyed by the terrible name “branch” for something that acts more like a bookmark (or “wandering tag” indeed!). And then I learned that git branches are branches in exactly the same way that the first element of a linked list in C “is” the linked list. Git was made by C people and they’re used to referring to entire data structures by way of some root element. I mean that doesn’t make me dislike the name any less but at least now I see where they were coming from.

neuromanser 3y ago
That's (most probably) where the "head" terminology comes from, too.
- alfredpawney 3y ago
  Yes you are correct. It traces back to Allen Newell
mr_mitm 3y ago
When the entire structure of commits is called a tree, I find the name "branch" fitting. The branch is identified by its head commit, so the path from head to root is uniquely defined and that's the branch. (Disregarding merges for now.)
- cpeterso 3y ago
  Leaning into the tree metaphor (and following the precedent of other version control systems), git should have used the term trunk instead of master or main.
  - hnarn 3y ago
    Why? That would heavily imply that master/main is somehow technically different from all other branches (since a trunk is certainly not a branch), which to my knowledge is not true.
    - cpeterso 3y ago
      I see what you mean, but don't "master" and "main" also imply some special authority? Trunk-based development with branches forking off and merging back into the trunk (a DAG, unlike a real tree! :) is an extremely common workflow. https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
  - Kuraj 3y ago
    By following this metaphor, a trunk would be the original commit, whereas branches are the tree branch tips.
    - galaxyLogic 3y ago
      And consider that because every folder can have its own .git subfolder, we can have several paralle trunks/repositories at the same time, meaning we have a forest. I haven't really seen specific guidelines as to when and why should anyone start a new repo. Are there some? Or is "mono-repo" the best solution, and when and for whom. Surely we need more than one git-repo in the whole world?!
- TeMPOraL 3y ago
  > Disregarding merges for now. Without disregarding them, it's not a tree, but a DAG.
  - dayjaby 3y ago
    It is a tree. What makes you think it's just a DAG? Are there commits with multiple parent commits or what?
    - imron 3y ago
      Yes. Merge commits have two parents.
      - Izkata 3y ago
        Two or more. I'm not sure there's a limit. Try not to do this (imagine a 5-way merge conflict).
    - zaphar 3y ago
      There absolutely can be. Merge commits have multiple parent commits for example. It's definitely a graph not just a tree.
      - dayjaby 3y ago
        Parent comment was about disregarding merge commits.
        zaphar 3y ago
        You can't disregard merge commits. It's part of the structure.
- skrebbel 3y ago
  FWIW “tree” has a specific, different meaning in Git. It’s a file tracking the contents of a directory.
- lmm 3y ago
  Well yes if you disregard the thing that makes it not a tree then it is a tree. But you can't disregard that!
ajross 3y ago
> Git was made by C people and they’re used to referring to entire data structures by way of some root element. FWIW this is actually backwards. The word "branch" was already in common use (to refer to the same basic idea) in SCM systems going back decades, and in almost all of those a "branch" was indeed a first class object with its own data that acted as a "container" for commits, both semantically and physically. The fact that a "branch" is just a pointer is in fact a git innovation on top of the former idea.
cpeterso 3y ago
> acts more like a bookmark In fact, Mercurial uses the term “bookmark” for its lightweight, git-like branching. Mercurial’s branches have slightly different semantics and can’t be deleted like bookmarks or git branches
deleted 3y ago
[deleted]
imron 3y ago
> Git was made by C people This is why I think of branches as pointers. The file contents are literally just a pointer to a commit on the DAG.
OJFord 3y ago
I don't see the problem? Real natural tree branches grow. If you move the branch to point somewhere else, then it's better/more accurately said that you changed the name to refer to a different branch. We can think of branches as the chains of commits; it's the names we give them that 'wander' both as we commit and if we move them to a different branch. But merging (as it were!) the concepts of branches and names for their tips is convenient, and often equivalent/inconsequential.

neuromanser 3y ago

That's (most probably) where the "head" terminology comes from, too.

alfredpawney 3y ago
Yes you are correct. It traces back to Allen Newell

mr_mitm 3y ago

When the entire structure of commits is called a tree, I find the name "branch" fitting. The branch is identified by its head commit, so the path from head to root is uniquely defined and that's the branch. (Disregarding merges for now.)

cpeterso 3y ago
Leaning into the tree metaphor (and following the precedent of other version control systems), git should have used the term trunk instead of master or main.
- hnarn 3y ago
  Why? That would heavily imply that master/main is somehow technically different from all other branches (since a trunk is certainly not a branch), which to my knowledge is not true.
  - cpeterso 3y ago
    I see what you mean, but don't "master" and "main" also imply some special authority? Trunk-based development with branches forking off and merging back into the trunk (a DAG, unlike a real tree! :) is an extremely common workflow. https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
- Kuraj 3y ago
  By following this metaphor, a trunk would be the original commit, whereas branches are the tree branch tips.
  - galaxyLogic 3y ago
    And consider that because every folder can have its own .git subfolder, we can have several paralle trunks/repositories at the same time, meaning we have a forest. I haven't really seen specific guidelines as to when and why should anyone start a new repo. Are there some? Or is "mono-repo" the best solution, and when and for whom. Surely we need more than one git-repo in the whole world?!
TeMPOraL 3y ago
> Disregarding merges for now. Without disregarding them, it's not a tree, but a DAG.
- dayjaby 3y ago
  It is a tree. What makes you think it's just a DAG? Are there commits with multiple parent commits or what?
  - imron 3y ago
    Yes. Merge commits have two parents.
    - Izkata 3y ago
      Two or more. I'm not sure there's a limit. Try not to do this (imagine a 5-way merge conflict).
  - zaphar 3y ago
    There absolutely can be. Merge commits have multiple parent commits for example. It's definitely a graph not just a tree.
    - dayjaby 3y ago
      Parent comment was about disregarding merge commits.
      - zaphar 3y ago
        You can't disregard merge commits. It's part of the structure.
skrebbel 3y ago
FWIW “tree” has a specific, different meaning in Git. It’s a file tracking the contents of a directory.
lmm 3y ago
Well yes if you disregard the thing that makes it not a tree then it is a tree. But you can't disregard that!

ajross 3y ago

> Git was made by C people and they’re used to referring to entire data structures by way of some root element. FWIW this is actually backwards. The word "branch" was already in common use (to refer to the same basic idea) in SCM systems going back decades, and in almost all of those a "branch" was indeed a first class object with its own data that acted as a "container" for commits, both semantically and physically. The fact that a "branch" is just a pointer is in fact a git innovation on top of the former idea.

cpeterso 3y ago

> acts more like a bookmark In fact, Mercurial uses the term “bookmark” for its lightweight, git-like branching. Mercurial’s branches have slightly different semantics and can’t be deleted like bookmarks or git branches

deleted 3y ago

[deleted]

imron 3y ago

> Git was made by C people This is why I think of branches as pointers. The file contents are literally just a pointer to a commit on the DAG.

OJFord 3y ago

I don't see the problem? Real natural tree branches grow. If you move the branch to point somewhere else, then it's better/more accurately said that you changed the name to refer to a different branch. We can think of branches as the chains of commits; it's the names we give them that 'wander' both as we commit and if we move them to a different branch. But merging (as it were!) the concepts of branches and names for their tips is convenient, and often equivalent/inconsequential.