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.
For a specific example of where choosing a name ("branch") which obfuscates the fact that you are actually manipulating a pointer, maybe consider what it means to delete a branch? Or create one for that matter.
Same in general programming, being clear on the difference between a reference and referee is vital to proper conceptualize what the operations actually do.
But I'm not sure even that's convincing as after using git for a while it becomes completely instinctual which is why it may not seem important to clearly identify a pointer to a commit and an actual sequence of commits related by the parent/child relationship.
I’m not following. Creating and deleting branches is easy in git without knowing it’s a pointer. What exactly is confusing about it, and how does knowing it’s a pointer help? Creating and deleting branches in Perforce is also easy, and they’re not pointers.
