4 ms·

I dunno - for me git doesn't really have branches. What it calls "branches" could more accurately be called version/commit pointers. A "branch" traditionally

by derriz 2y ago

I dunno - for me git doesn't really have branches. What it calls "branches" could more accurately be called version/commit pointers. A "branch" traditionally in SCM was a sequence of versions/commits. In those SCMs, the "main" (or master) branch was an identifiable sequence of versions/commits. There isn't a "main" branch in git, there's a current "main" version/commit. If your history is fully linear, a pointer to the "main" commit allows you, via parent following, to discern a "main" branch. But if you've been using merge, for example, there isn't a unique path from the current main commit to the root.

PhilipRoman 2y ago
This does sometimes cause problems when trying to understand history. Would love if git recorded the current branch name (if any) somewhere in the commit
- imron 2y ago
  I have a git commit hook that automatically adds a git trailer containing the jira ticket/issue number to the commit message. It gets this from the branch name which by my convention always contains the ticket ref. It would be trivial to modify this to use the full branch name instead.
  - imron 2y ago
    And now I'm on my computer, here is the modified version. Put this in: .git/hooks/prepare-commit-msg #!/usr/bin/env bash BRANCH=$(git symbolic-ref --short HEAD 2> /dev/null) # fail gracefully if we don't have a branch if [ -z "$BRANCH" ]; then exit 0 fi # add a git trailer with the branch git interpret-trailers --in-place --where before --if-exists addIfDifferent --trailer Branch="$BRANCH" "$1" And if you add the following alias to your ~/.gitconfig you'll be able to see the branch names in the logs by typing git lb (for log branch): [alias] lb = log --color --graph --pretty=format:'%Cred%h%Creset %C(bold)%(trailers:key=Branch,valueonly,separator=%x2c)%Creset - %s %Cgreen(%cr)%C(bold blue) <%an>%C(nobold yellow)%d%Creset' --abbrev-commit
    - cryptonector 2y ago
      I'm thinking of writing a commit hook to make sure that every commit has the following metadata in trailers: - original parent commit Between this and the synopsis it should then be possible to find all evolutions of this commit. - original upstream URI and branch (if known) or upstream URI and branch targeted for integration (prompting if necessary) - commit type and optional tracker ID When a commit has these metadata already, leave it.
User23 2y ago
Understanding refs is key to understanding Git. It’s not really difficult and a lot of mystifying cargo cult stuff suddenly becomes intuitive once you realizing you’re pretty much just manipulating pointers into a directed acyclic graph where each node has between 0 and 2 parents.
- Zambyte 2y ago
  0 and >0 parents technically, but in practice usually between 0 and 2. Merge commits (commits with >1 parent) can have more than 2 parents.
dahart 2y ago
Meh getting too reductionist doesn’t necessarily help anything. Branching is a concept, not an implementation detail. There is a “main” branch in git because that’s how people talk about it, and what they usually mean when they refer to “main” or another branch; people are not usually referring to a singular tip-of-the-branch commit, but the whole branch and it’s history. A branch is different from a tag or a commit because the branch is expected to move frequently (point to different commits) and tags/commits aren’t. The implementation isn’t different, but the usage and meaning is. Branches in other SCMs are really no different conceptually. Perforce doesn’t identify any unique path from the tip of the branch to the root it came from, you can merge both directions. Same is true in other SCMs.
- derriz 2y ago
  It's more than an implementation detail. Without changing the DAG, I can arbitrarily move "main" to point at any commit I like in git. This isn't some esoteric action - this is done constantly as part of normal git workflow. While what people understand as a branch in traditional SCM discussions can only grow by the addition of new versions. Commits/versions belong to a specific and unique branch and once added to the version tree, cannot "move" branches. While in git, a commit can belong to any number of (git) "branches" which makes presenting a true branch based history (if the DAG contains merges) impossible. Which is why we all end up using a workflow based on rebase instead of one based branch-and-merge. I've observed how much confusion using the name "branch" for what is a version pointer in git causes to those starting with git. The easiest way I've found to help people is to tell them forget about the word "branch" and think in terms of the DAG and pointers to elements in the DAG.
  - dahart 2y ago
    Sure git is a bit different than P4 or Svn or whatever; they all have unique implementation details. I don’t disagree that git confusion sometimes exists nor that you’ve seen it, but it might make your point clearer to give a specific example, one that knowing a branch is a pointer fixes. I’m not sure if it’s useful to think of commits as immovable; they can be rebased and cherry picked, the “version” (SHA) is another implementation detail. Moving the content of commits around is common standard practice with git. That’s a different type of move than a branch move, not what I was referring to above, but I guess I’m arguing that branching is more about workflows, conventions, and conceptual understanding than how it works technically. You’re right that it’s sometimes useful to know that a git branch is a pointer and super lightweight, but that doesn’t help you differentiate branches and tags, for example. Git has a bunch of features that are ‘just’ a pointer. Knowing that is good for advanced workflows, but not really necessary for basic version control.
Zambyte 2y ago
Jujutsu is a great interface to the git data structures, and it makes all of this obviously true.
cryptonector 2y ago
A proper branch in Git is just a name for a commit with the rule that when you commit to a branch you move the name to point to the new commit, and similar rules on push.

by derriz 2y ago

PhilipRoman 2y ago

This does sometimes cause problems when trying to understand history. Would love if git recorded the current branch name (if any) somewhere in the commit

imron 2y ago
I have a git commit hook that automatically adds a git trailer containing the jira ticket/issue number to the commit message. It gets this from the branch name which by my convention always contains the ticket ref. It would be trivial to modify this to use the full branch name instead.
- imron 2y ago
  And now I'm on my computer, here is the modified version. Put this in: .git/hooks/prepare-commit-msg #!/usr/bin/env bash BRANCH=$(git symbolic-ref --short HEAD 2> /dev/null) # fail gracefully if we don't have a branch if [ -z "$BRANCH" ]; then exit 0 fi # add a git trailer with the branch git interpret-trailers --in-place --where before --if-exists addIfDifferent --trailer Branch="$BRANCH" "$1" And if you add the following alias to your ~/.gitconfig you'll be able to see the branch names in the logs by typing git lb (for log branch): [alias] lb = log --color --graph --pretty=format:'%Cred%h%Creset %C(bold)%(trailers:key=Branch,valueonly,separator=%x2c)%Creset - %s %Cgreen(%cr)%C(bold blue) <%an>%C(nobold yellow)%d%Creset' --abbrev-commit
  - cryptonector 2y ago
    I'm thinking of writing a commit hook to make sure that every commit has the following metadata in trailers: - original parent commit Between this and the synopsis it should then be possible to find all evolutions of this commit. - original upstream URI and branch (if known) or upstream URI and branch targeted for integration (prompting if necessary) - commit type and optional tracker ID When a commit has these metadata already, leave it.

User23 2y ago

Understanding refs is key to understanding Git. It’s not really difficult and a lot of mystifying cargo cult stuff suddenly becomes intuitive once you realizing you’re pretty much just manipulating pointers into a directed acyclic graph where each node has between 0 and 2 parents.

Zambyte 2y ago
0 and >0 parents technically, but in practice usually between 0 and 2. Merge commits (commits with >1 parent) can have more than 2 parents.

dahart 2y ago

Meh getting too reductionist doesn’t necessarily help anything. Branching is a concept, not an implementation detail. There is a “main” branch in git because that’s how people talk about it, and what they usually mean when they refer to “main” or another branch; people are not usually referring to a singular tip-of-the-branch commit, but the whole branch and it’s history. A branch is different from a tag or a commit because the branch is expected to move frequently (point to different commits) and tags/commits aren’t. The implementation isn’t different, but the usage and meaning is. Branches in other SCMs are really no different conceptually. Perforce doesn’t identify any unique path from the tip of the branch to the root it came from, you can merge both directions. Same is true in other SCMs.

derriz 2y ago
It's more than an implementation detail. Without changing the DAG, I can arbitrarily move "main" to point at any commit I like in git. This isn't some esoteric action - this is done constantly as part of normal git workflow. While what people understand as a branch in traditional SCM discussions can only grow by the addition of new versions. Commits/versions belong to a specific and unique branch and once added to the version tree, cannot "move" branches. While in git, a commit can belong to any number of (git) "branches" which makes presenting a true branch based history (if the DAG contains merges) impossible. Which is why we all end up using a workflow based on rebase instead of one based branch-and-merge. I've observed how much confusion using the name "branch" for what is a version pointer in git causes to those starting with git. The easiest way I've found to help people is to tell them forget about the word "branch" and think in terms of the DAG and pointers to elements in the DAG.
- dahart 2y ago
  Sure git is a bit different than P4 or Svn or whatever; they all have unique implementation details. I don’t disagree that git confusion sometimes exists nor that you’ve seen it, but it might make your point clearer to give a specific example, one that knowing a branch is a pointer fixes. I’m not sure if it’s useful to think of commits as immovable; they can be rebased and cherry picked, the “version” (SHA) is another implementation detail. Moving the content of commits around is common standard practice with git. That’s a different type of move than a branch move, not what I was referring to above, but I guess I’m arguing that branching is more about workflows, conventions, and conceptual understanding than how it works technically. You’re right that it’s sometimes useful to know that a git branch is a pointer and super lightweight, but that doesn’t help you differentiate branches and tags, for example. Git has a bunch of features that are ‘just’ a pointer. Knowing that is good for advanced workflows, but not really necessary for basic version control.

Zambyte 2y ago

Jujutsu is a great interface to the git data structures, and it makes all of this obviously true.

cryptonector 2y ago

A proper branch in Git is just a name for a commit with the rule that when you commit to a branch you move the name to point to the new commit, and similar rules on push.