Hacker News Reader

Comment by cybrexalpha | Hacker News Reader

> It's true that Git implements branches as refs, plus also a nebulous implicit part that varies from command to command. But that's an unfortunate implementation detail, not something we should be committed to.

I actually find git way easier to understand if I don't think about branches in the way the author suggests. My mental model for git really is commits and refs, and it helps me use it fluently. When I wave my hands around and say "a branch is nothing but a ref" what I actually mean is "...and so you should understand how it actually works, so what I'm about to do doesn't look like magic".

View on HN

I think you and the author are right, but addressing different audiences.

I think most people come to git with their own mental model of what a branch is, what a merge is, etc.

Learning git is often mostly undoing their preconceptions (ie by saying 'a branch is just a ref').

But ultimately, we humans tend to think of a branch as a branch, not a ref. For instance, the previous sentence probably made perfect sense to you.

I agree, and would add that this is exactly what the OP is saying when it talks about this being a communication issue. Saying "a branch is just a ref" is the right attitude for talking to git and making it do what you want it to do, but it's the wrong attitude when you are writing or talking about code, in which case branches are the reification of the processes by which your code evolves.

Do they? I certainly had no intuitive notion of how version control would work before I learned git for the first time.

You did have an intuitive notion of what the word "branch" means, though.

Yep, I was taught that at first place. People who taught me about git describe branch as a marker on commit. And I never has confusion about it.

Probably people confuse about this has experiments with some other version control system. So they already has some specific meaning attached to the name "branch" ?

Reply on news.ycombinator.com