poll: how do you think about git branches? (I'll put an image in a reply with pictures for the 3 options)
@b0rk #1 doesn't make any sense and easily falls apart at edge cases, if you think this way you'll sooner or later make yourself confused; #2 can be useful when reasoning or talking about repo topology as a kind of mental shortcut (and actually applies to any commit, not just those pointed to by branches); #3 is the truth.
@wouter @b0rk The question was about git branches specifically, your reply seems off-topic to me. The implementation doesn't matter (otherwise the answer would be "it's a file"); what matters is git's data model, which is what the user operates on conceptually and where the concept of branch is clearly defined. When the model in your head doesn't match the real one, you're setting yourself up for trouble (or xkcd 1597 :P)
Respectfully disagree.
The question was, how do you think about git branches.
I know that the technical implementation of a git branch is just a pointer to a single commit which can move around to other commits, with some overridable safeguards so you don't get too surprised when things are done. However, that's not a very useful way to think about it, IMO.
@b0rk
@wouter @b0rk It's not "technical implementation", it's the whole concept of a branch in git. Understanding that lets you use branches in git with ease regardless of context they appear in. You don't have to bother with technical implementation at all, it doesn't matter - the concept does.
The option one does not help to understand git, I have repos where branches don't "branch off" from any common point at all. Such a model in one's head just causes confusion.
@wouter @b0rk The problem is that "branch" in git is a term that describes something else than the concept of "branching" in VCS means in general. Git branches can be used to support "VCS branching" workflows, but they can support other workflows too. It's crucial to understand what "branch" actually is in git's data model when one wants to get comfortable with git, and it has nothing to do with implementation details.
I'm very much aware, thanks for git 101 (which I'm not needing, thanks)
I think that how you think about your daily work is sometimes more important than how the software itself works. For git branches, this very much applies.
You seem to disagree, which is fine. But just because the way I usually think about things is different from how things really are, doesn't mean I don't know how things really work.
@b0rk
@wouter @b0rk I don't care about how git works and how it's implemented. I care about the model of data I work on when using it, and what I'm describing is how I think about it in my daily work, which helps me tremendously compared to some flawed models I used to apply in the past when I was less experienced.
Obviously there's a limit to how far you can go with this, but then I'm not advocating a model that does not even partially map onto the way things really are.
Git's data model is awesome and great and can let you do massively impressive things, but I just want to write code, you know? And I'll fall back on it when my simple model doesn't work, but for day to day things? Nah, thanks.
@b0rk
And that's fine.
What I'm saying is that I find it much easier to just Get Stuff Done if I use a mental model that is closer to how I work than it is to the actual implementation of things.
You seem to prefer the opposite.
None of this makes either you or me wrong, it just means we're different 🤷
@b0rk