3 ms·

The "Current Branch" in Git

29 points by ingve 3y ago

deleted 3y ago
[deleted]
milliams 3y ago
To me the "current branch" means, if I make a commit, what will be updated to point at the new commit.
globular-toast 3y ago
You're either in a detached HEAD state or you're not. Detached means HEAD points to a commit, otherwise it points to a branch. "Current branch" only makes sense when HEAD points to a branch. Otherwise, there is no "current branch".
- Zambyte 3y ago
  HEAD is always a reference to the checked out commit. A "branch" is a named reference to a commit to a commit that will auto advance if you check it out and make new commits. A tag is a named reference to a commit that will not auto advance if you check it out and make new commits. If you checkout a commit using something other than a branch name, new commits that you make will not auto advance any branches. This is what a "detached HEAD" is, since your HEAD is detached from any branch.
  - happytoexplain 3y ago
    You're speaking at one level of abstraction up from the post you're replying to. You're both correct. It's just that you need to use the parent's level of abstraction if you want to strictly define "current branch".
    - globular-toast 3y ago
      One of the difficult things with git is it's hard to know which level of abstraction people are talking about. As I was typing my first comment I thought "well I guess a detached HEAD state is a branch too, as a branch is just a chain of commits". But that's at a completely different level of abstraction to where the OP is at. I would be at the "git as just a big ol' DAG" level but the OP is at the "git as a version control system" level.
happytoexplain 3y ago
I forgot that HEAD doesn't point to tags! I guess it makes some semantic sense - tags are just labels, and shouldn't "carry" anything with them if they move. Great writeup. Technically "current branch" is easily defined: It's the branch (not commit or tag) HEAD points to, if any. "The last thing I checked out" is really just the last identifier you passed to 'git checkout', not what that resolved to and actually got checked out, or any commit-ish that HEAD has been pointed to in the meantime by other commands. "What's shown on my git prompt" could be any silly thing, since that's not git. However, colloquially (and even sometimes in the Git documentation itself!), "current branch" can mean other things, as the author enumerates, and it would be unrealistic to ignore that. One note: It's silly that git prompts seem to choose an arbitrary tag to show when there's multiple - they should show all of them or none of them. However, the author says that 'git status' does the same thing, but for me (git 2.44.0), it does not report any tags, which makes sense to me (reporting all tags along with the SHA would also make sense).
cxr 3y ago
This is a much better post than the one that preceded it. Still... The biggest problem with people's attempts to wrap their heads around Git, its awful UI notwithstanding, seems to be an insistence on thinking of it foremost in terms of the experience of running any given command. I.e., trying to understand it from the outside in. Indeed, it's awful UI certainly hurts the process. Git's the stupid content tracker. Take a work consisting of a bunch of files, snapshot them, then create a new work (consisting of a lot of similar files, to be sure, but where others differ in some way). Git concerns itself with both of these collections as collections. It's true that it's got all this "branching" imagery, but that's an attempt to describe the relationships between the collections from the metadata attached to each one (collection 0ffcd473 calls collection f7d0c770 its parent). The branches are synthetic, imaginary. Not a lot different from a family tree or the "branches" you would get if you started mapping out the provenance of religious texts copied from another but each with their own copying errors (or deliberately editorialized content). The branches aren't really there—they exist as an aide for the researcher. The only real difference is that Git actually has explicit metadata, but still, the branches aren't there. Focusing on Git's on-disk representation or other internals misses the point. The main thing is getting the files in the collection you're putting together right now to look the way you intend right now. Everything else is recordkeeping. (At least it should be—anything (whether it be a given tool, workflow, etc) that depends on it being any more complicated than this is fundamentally broken.) Git's whole deal was about being an alternative to manually futzing around with tarballs and/or multiple directories of source code sitting next to each other on your disk. (It's still that, but with a somewhat involved—but not very interesting—deduplication scheme in userspace. The other details are even less interesting than that.)
- happytoexplain 3y ago
  IMO the best way to think about git is at a happy medium level of abstraction (which most people tend toward anyways, it seems), where a commit is a snapshot, but can be thought of as the diff from its parent to it; a repo is a tree of commits over time (where lines can merge, so it's technically a graph, rather than a tree); a branch is a series of commits represented by a pointer pointing to the last commit in the branch, and you can think of that series of commits as either going back all the way to the initial commit or just back to another branch from which it diverges, depending on what you're doing with it. Etc. And then the commands operate on those things to achieve the logical goal of the command. Re: Bad UI, I vacillate, but I don't disagree. I do think it needs to be said that people talk about git's internals not necessarily because the UI is bad, but also because git is so relatively clean and simple that you can talk about the internals. Conversations about other tools look simpler because most people can not reasonably talk about their internals in a casual format. So, in a weird way, conversations about git are complicated because, unlike with so much other software, people don't just throw up their hands and get along the best they can, talking only about the UI and the results of using the UI, living with a limited, abstract understanding. Git enables them to understand better, with some effort.

29 points by ingve 3y ago

deleted 3y ago

[deleted]

milliams 3y ago

To me the "current branch" means, if I make a commit, what will be updated to point at the new commit.

globular-toast 3y ago

You're either in a detached HEAD state or you're not. Detached means HEAD points to a commit, otherwise it points to a branch. "Current branch" only makes sense when HEAD points to a branch. Otherwise, there is no "current branch".

Zambyte 3y ago
HEAD is always a reference to the checked out commit. A "branch" is a named reference to a commit to a commit that will auto advance if you check it out and make new commits. A tag is a named reference to a commit that will not auto advance if you check it out and make new commits. If you checkout a commit using something other than a branch name, new commits that you make will not auto advance any branches. This is what a "detached HEAD" is, since your HEAD is detached from any branch.
- happytoexplain 3y ago
  You're speaking at one level of abstraction up from the post you're replying to. You're both correct. It's just that you need to use the parent's level of abstraction if you want to strictly define "current branch".
  - globular-toast 3y ago
    One of the difficult things with git is it's hard to know which level of abstraction people are talking about. As I was typing my first comment I thought "well I guess a detached HEAD state is a branch too, as a branch is just a chain of commits". But that's at a completely different level of abstraction to where the OP is at. I would be at the "git as just a big ol' DAG" level but the OP is at the "git as a version control system" level.

happytoexplain 3y ago

I forgot that HEAD doesn't point to tags! I guess it makes some semantic sense - tags are just labels, and shouldn't "carry" anything with them if they move. Great writeup. Technically "current branch" is easily defined: It's the branch (not commit or tag) HEAD points to, if any. "The last thing I checked out" is really just the last identifier you passed to 'git checkout', not what that resolved to and actually got checked out, or any commit-ish that HEAD has been pointed to in the meantime by other commands. "What's shown on my git prompt" could be any silly thing, since that's not git. However, colloquially (and even sometimes in the Git documentation itself!), "current branch" can mean other things, as the author enumerates, and it would be unrealistic to ignore that. One note: It's silly that git prompts seem to choose an arbitrary tag to show when there's multiple - they should show all of them or none of them. However, the author says that 'git status' does the same thing, but for me (git 2.44.0), it does not report any tags, which makes sense to me (reporting all tags along with the SHA would also make sense).

cxr 3y ago

This is a much better post than the one that preceded it. Still... The biggest problem with people's attempts to wrap their heads around Git, its awful UI notwithstanding, seems to be an insistence on thinking of it foremost in terms of the experience of running any given command. I.e., trying to understand it from the outside in. Indeed, it's awful UI certainly hurts the process. Git's the stupid content tracker. Take a work consisting of a bunch of files, snapshot them, then create a new work (consisting of a lot of similar files, to be sure, but where others differ in some way). Git concerns itself with both of these collections as collections. It's true that it's got all this "branching" imagery, but that's an attempt to describe the relationships between the collections from the metadata attached to each one (collection 0ffcd473 calls collection f7d0c770 its parent). The branches are synthetic, imaginary. Not a lot different from a family tree or the "branches" you would get if you started mapping out the provenance of religious texts copied from another but each with their own copying errors (or deliberately editorialized content). The branches aren't really there—they exist as an aide for the researcher. The only real difference is that Git actually has explicit metadata, but still, the branches aren't there. Focusing on Git's on-disk representation or other internals misses the point. The main thing is getting the files in the collection you're putting together right now to look the way you intend right now. Everything else is recordkeeping. (At least it should be—anything (whether it be a given tool, workflow, etc) that depends on it being any more complicated than this is fundamentally broken.) Git's whole deal was about being an alternative to manually futzing around with tarballs and/or multiple directories of source code sitting next to each other on your disk. (It's still that, but with a somewhat involved—but not very interesting—deduplication scheme in userspace. The other details are even less interesting than that.)

happytoexplain 3y ago
IMO the best way to think about git is at a happy medium level of abstraction (which most people tend toward anyways, it seems), where a commit is a snapshot, but can be thought of as the diff from its parent to it; a repo is a tree of commits over time (where lines can merge, so it's technically a graph, rather than a tree); a branch is a series of commits represented by a pointer pointing to the last commit in the branch, and you can think of that series of commits as either going back all the way to the initial commit or just back to another branch from which it diverges, depending on what you're doing with it. Etc. And then the commands operate on those things to achieve the logical goal of the command. Re: Bad UI, I vacillate, but I don't disagree. I do think it needs to be said that people talk about git's internals not necessarily because the UI is bad, but also because git is so relatively clean and simple that you can talk about the internals. Conversations about other tools look simpler because most people can not reasonably talk about their internals in a casual format. So, in a weird way, conversations about git are complicated because, unlike with so much other software, people don't just throw up their hands and get along the best they can, talking only about the UI and the results of using the UI, living with a limited, abstract understanding. Git enables them to understand better, with some effort.