Yes, git is deficient. It’s a unique case where the underlying model is simpler than the UI and abstractions built on top of it. But there’s no sign of this changing anytime soon, so I think it’s fine to accept it, along with the fact that branches really are named refs to commits. Trying to explain branches in less abstraction-leaking ways just makes git operations on branches seem even weirder than they already are.
I think the point of “git branches are just refs” is that when you come to use branches as they are implemented in Git you are going to hit the leaky abstraction very quickly. In which case, it is very helpful to know that git-the-software has a very different implementation of branches than what is implied by much of our usage of the term branch.
You have expressed clearly and more succinctly what I was going to write.
Moving between version control systems you need to know what it does differently in order to rebuild your day-to-day process that you have on top, especially if the different systems use same or similar enough terminology for slightly different things that misconceptions might arise from it, in which case the things might as well be completely different.
It doesn’t matter if it’s a leaky abstraction*, or if the terminology is different from common terminology, or not. It may affect your decision to adopt, or not, git as your version control system, but once selected you need to understand how it works.
*if you were moving away from git, does that mean you might now have problems with water-tight abstractions?
I only really understood git the day I stopped thinking about branch as a real thing, and just used the concept of a ref to a commit. Everything suddenly made much more sense.
Huh, that’s a really interesting article. Not really the discussion of git, but how it differentiates between how people talk about software (and actually use it) and how it’s implemented. This example make it very clear that an application is more than just code. Good stuff.
There’s a level of nitpicking where it becomes a hindrance, I agree with that. But computers are nitpicky motherfuckers, and as their users, we can’t afford to not be nitpickers, too, at least to a certain extent.
If we always talk about branches as if they exist, it’s easy to forget that, other than conceptually, they don’t, as the author stated:
the Git software doesn’t have any formal representation of branches
I feel like I seen way more people struggling to understand things because their mental model doesn’t exist other than in concept, than the other way around.
Specially when dealing with leaky abstractions, keeping in mind that they are, in fact, leaky, and communicating this to people learning said abstractions, is crucial.
The problem with this view is that you still can’t answer the question of whether the upstream branch contains a commit. For example, in FreeBSD work is done in the main branch and then cherry-picked back to the various stable branches. The only way for git to determine if a branch contains a particular commit is to do some fuzzy matching on the whole history. The commit itself does not have identity and so the same commit applied to different branches will show up with different hashes. This is something that, I believe, Pijul fixes.
Yes,
gitis deficient. It’s a unique case where the underlying model is simpler than the UI and abstractions built on top of it. But there’s no sign of this changing anytime soon, so I think it’s fine to accept it, along with the fact that branches really are named refs to commits. Trying to explain branches in less abstraction-leaking ways just makes git operations on branches seem even weirder than they already are.I think the point of “git branches are just refs” is that when you come to use branches as they are implemented in Git you are going to hit the leaky abstraction very quickly. In which case, it is very helpful to know that git-the-software has a very different implementation of branches than what is implied by much of our usage of the term branch.
You have expressed clearly and more succinctly what I was going to write.
Moving between version control systems you need to know what it does differently in order to rebuild your day-to-day process that you have on top, especially if the different systems use same or similar enough terminology for slightly different things that misconceptions might arise from it, in which case the things might as well be completely different.
It doesn’t matter if it’s a leaky abstraction*, or if the terminology is different from common terminology, or not. It may affect your decision to adopt, or not, git as your version control system, but once selected you need to understand how it works.
*if you were moving away from git, does that mean you might now have problems with water-tight abstractions?
Boy if you think branches are a leaky abstraction in git, wait until you see what CVS considers a branch. Just a sequence of diffs with the same tag.
I only really understood git the day I stopped thinking about branch as a real thing, and just used the concept of a ref to a commit. Everything suddenly made much more sense.
If this is the article that sparked the discussion - the quote is pulled from it - then this reply seems more than reasonable.
Huh, that’s a really interesting article. Not really the discussion of git, but how it differentiates between how people talk about software (and actually use it) and how it’s implemented. This example make it very clear that an application is more than just code. Good stuff.
There’s a level of nitpicking where it becomes a hindrance, I agree with that. But computers are nitpicky motherfuckers, and as their users, we can’t afford to not be nitpickers, too, at least to a certain extent.
If we always talk about branches as if they exist, it’s easy to forget that, other than conceptually, they don’t, as the author stated:
I feel like I seen way more people struggling to understand things because their mental model doesn’t exist other than in concept, than the other way around.
Specially when dealing with leaky abstractions, keeping in mind that they are, in fact, leaky, and communicating this to people learning said abstractions, is crucial.
The problem with this view is that you still can’t answer the question of whether the upstream branch contains a commit. For example, in FreeBSD work is done in the main branch and then cherry-picked back to the various stable branches. The only way for git to determine if a branch contains a particular commit is to do some fuzzy matching on the whole history. The commit itself does not have identity and so the same commit applied to different branches will show up with different hashes. This is something that, I believe, Pijul fixes.
Gerrit adds change IDs to Git commit messages for this same reason.