This is an interesting idea. You said:
why a branch is only a pointer to a commit?
seem useful to also track an additional piece piece of data that would point to a parent branch, and when you create a new branch with checkout -b, it would get the current branch you are in and set that as the parent of the new branch.
How would you change the definition of a branch so that you can always get the parent branch even if:
The parent branch is deleted
The parent branch and the child branch diverge completely from the branch point
The parent branch is rebased
The child branch is rebased
As for why the branching mechanism is designed the way it is, git's branching mechanism is incredibly lightweight compared to the version control systems that came before it. This is partially because a branch is just a ref. All it takes to create a new branch is to create a tiny file in `.git/refs/heads`.
Additionally, the reason why it is designed this way may have to do with git being a distributed version control system. For example, if I execute `git fetch branch-name`, git knows I need to download the set of objects that I do not already have that are directly tied to `branch-name` or any of its parent commits. If we hard-code this parent branch concept, would I also now need to download the set of objects associated with the parent branch? And its parent branch? And its parent branch? And ... ad infinitum?
With that said, what problem are you trying to solve by determining the parent branch of a pull request? Perhaps there is something we can suggest if you tell us a bit more?
... View more