> 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....
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.