[yankjenets]

By "remove a commit" do you mean rebase A to point at its previous commit, HEAD~1?

A commit SHA represents the entire DAG up until that point, not a given changeset. So in your example, branch B is still a pointer to a commit, and branch A is a pointer to a different commit. Where is the convenient lie?

[nophunphil]

That is one way to “remove a commit” and I agree with your analysis for that case.

The method I had in mind is an interactive rebase. Assume there are n > 5 commits on my branch, choosing 5 arbitrarily. If I run “git rebase -i HEAD~5” then use the “drop” command on the third-most-recent commit, I do end up with a different DAG. The change is subtractive and not just the removal of the current HEAD.

This kind of history change is definitely a bit less common but not obscure by any means. I’ve rebased to drop commits on my own feature branches many times.

[yankjenets]

Ah ok, understood.

I would argue that is still not a convenient lie of "a branch is a pointer to a commit". Rather, the rebase command is changing what the branch is pointing to, and git tries to make that clear.

After that rebase command, there is a message like `Successfully rebased and updated refs/heads/yourbranch`, showing that the branch named yourbranch is now pointing at something new.

Your original comment:

>Consider the case where I create a new branch B from A then remove a commit. The branch is now more like a "a pointer to a commit on a DAG" where branch B points to a commit on a different DAG than branch A.

My counterpoint taking this to the extreme:

>Consider the case where I create a new branch B from A then run git reset --hard SOMESHA1

In my example, again the new branch is pointing at a completely different commit--because I am repointing the branch.