Hacker News Reader

> Of course, that is the whole point of naming something sensibility..Just, for example, imagine how hard it would be if you have to learn/work in a version of C that calls pointers as 'branches'.

Yes, if you rename <arbitrary thing> to <other arbitrary thing>, it is very likely to result in nonsense. This is not such a case.

A branch in git is literally a name for a branch of the DAG that is the commit tree. It's possibly the least abstract interpretation of the concept as possible. There is nothing nonsensical about it.

But the objection seems to be that you don't work with it like in svn or hg or p4 or cvs (which are also all different from each other), which does not make it nonsensical, merely unfamiliar. This is the distinction I'm driving at.

>But the objection seems to be that you don't work with it..

The objection is that, when naming is skewed in lower levels it makes it harder to reason about higher level concepts and creates ambiguity..

For example, let us continue with the idea of a 'branch'...

Suppose you define a branch as 'a set of commits'. Then it is easy to imagine a 'remove' operation on a 'branch' will remove all the commits in that 'branch'. There is no ambiguity.

But when you define a branch as 'a pointer to the last commit in a consecutive set of commits', a 'remove' operation on a branch is no longer clear what it is supposed to do.

Does it simply deletes the pointer, in which case the commits will remain untouched? But it would not be consistent with the abstraction of the 'branch'.

Does it remove all the child commits from the history? by which the operation would be consistent with the abstraction of a 'branch'.

Now the remove operation is ambiguous as to what it actually does.

Note that there would be no ambiguity if the user does not know that a branch is actually a pointer to a commit. Because git hides all the change-sets that are not the decedents of a branch. So a users concept of a 'branch removal' is maintained. But I think it is pretty accepted that using git requires that you know stuff like these...

So another way of looking at the problem is that, Git forces the user to work at multiple levels of abstraction simultaneously. And this creates ambiguity because the user wouldn't know which level of abstraction to use when reasoning about something, and defeats the whole point of having abstractions in the first place IMHO.

> Then it is easy to imagine a 'remove' operation on a 'branch' will remove all the commits in that 'branch'. There is no ambiguity.

The problem is not with Git's use of pointers, but with your own thinking.

One should not be able to "remove" commits, because any operation should be undo-able. In git removing commits implies updating a pointer. And if those commits end up not being referenced by anything else, then they'll get garbage collected. What git does is very close to how persistent data-structures work. And many people complain about it just because it's unfamiliar.

And in your example, of course there's ambiguity, how can it not be? What happens with the branches that are forked from your branch? That's the definition of ambiguity right there.

> So another way of looking at the problem is that, Git forces the user to work at multiple levels of abstraction simultaneously.

In my experience, the problem with Git is that people don't bother to read documentation for a tool that they are using every day.

>What happens with the branches that are forked from your branch?

Care to elaborate? Do you mean when removing a branch, what happens to forked/child branches? There is no ambiguity, a change set cannot exist without it's parent or cannot be moved to a different parent without changing its identity. (The revision hash is a function of its ancestors too). So if you remove a branch, the forks/child branches will be removed as well.

Anyway, that was just a made up example to show how naming can affect reasoning. I don't think Mercurial or Git allows you to delete branches directly....

Since Git is graph based, there's no guarantee that removing the branch commits will work since there might be other branches using it.

Of course, if you delete a branch and then run git prune, its commits should disappear as long as they weren't part of another branch.

I think we all understand why git branches are called branches, the problem is that it's a misleading name.

Git branches are pointers to commits. For example I can move the pointer to a commit to point to the previous commit instead. But the commit which was previously being pointed to is still there. However when I say that I reset a branch to a previous commit, I get the feeling that the branch was "cut", and so that the commit was lost - which is not the case.

This is why using the name "bookmark" is better in my opinion. Not because I'm used to it (I've used git much more than mercurial), but because it's a better representation of what is actually happening.

For all intents and purposes, as long as no other branch is pointing to that commit, that commit is 'lost'. It's not immediately removed from your hard drive, but it's no longer considered part of your history.

Note that the technical name for branches in git is refs or references, which more accurately describe their nature.

> Of course, that is the whole point of naming something sensibility..Just, for example, imagine how hard it would be if you have to learn/work in a version of C that calls pointers as 'branches'.

Git was not named with Mercurial in mind. That's what they're saying, Git's naming only feels strange because you're coming from another VCS. I found Git's naming strange wen I came to it from SVN. When I tried Mercurial after that, I found it's naming strange. Everyone names things differently. It's not a Git issue.

> I don't know what you mean by 'several plugins to do branch like things'.

Maybe his knowledge of Mercurial is 5+ years old. In versions before 1.8 (2010 and before), bookmarks was an extension ("module") and you had to add a line in .hgrc to take it into use.

No, bookmarks were one of the two built-in versions I was referring to. I'm referring to things like this: http://mercurial.selenic.com/wiki/MqExtension

Just curious. What branch like things do you mean, when you say that you need Mq to do it? If you mean things like rebase, cherry pick, folding commits etc, those can be done in better ways by bundled in extensions like rebase, graft and historyedit.

Even some of the Mercurial developers does not like Mq extension much...