My view on it is that unfortunately there is no way to do that. Some things are going to be hard and that is it, you cannot make it easier. We see that in never ending stream of frameworks or "new/better/easier" ways which in the end become bloated in the same ways as most other stuff because problems don't go away if you don't know about them.
In the end data model of git is its killer feature because it gives me tools to deal with hard problems and do it efficiently.
I always feel that complaints like the one you’re replying to aren’t thought through. The simple follow up is: how would you do it better? There’s no better way. You only need to look at the complicated part of git for very complicated things. If you think about it, commits and branches are incredibly simple relative to what’s actually happening (when it comes to working with them, that is). Listening to old folks talk about pre-git version control gives me appreciation for just how good it is.
There are a few fixes I would make, but only a handful would be significant to everyday usage, none would involve fundamentally changing the underlying data model. The biggest would probably be to make all commits required to be made onto branches and either embed the data of what branch created a commit into the commit itself, or have a separate data store of branch-to-commit info, which would allow for "branches as a series of commits" to be a first class citizen besides "branches as references to a commit". Maybe add git notes-esque support for editable metadata on the branch, where you could put information that currently would be stored in some pull request management system.
The data regarding what branch a commit was made is available. It’s all available if you dig deep enough.
What you’re talking about sounds like the work of a git visualization tool made for fixing problems. I do love a repo viz where I can see the tree of branches for helping me understand where something went wrong. The surface level stuff people use day to day is as simple as it needs to be.
You can't identify the set of commits I and H (specifically, commits made under a given branch) without knowing (external to the information stored in commits normally) that branch2 branched off of branch1.
In short: I don’t know where, but I do know that it’s in there.
My logic is that I’ve used tools that viz what you’re talking about. They actually have much prettier versions of the (admittedly very nice, thank you) drawing you made. Bitbucket has one. These viz would be impossible to make without the info.
I read the git manual a couple of years ago. (All except the plumbing chapters.) There are commands that unveil deeper and deeper into whatever you’re querying, and it was in there somewhere. Give it a look. It’s a very nice manual. I read the whole thing (minus the plumbing) in less than 4 hours.
If I had to guess, I would say git reflog is involved.
My example was actually flawed. You can generate that information by iterating through all the heads, and then working backwards to the first commit that is reachable by another head. The better question, that Git actually can't answer, is whether E, F, and G were made under branch1 or branch2. Reflog could answer the question, but reflog is local only, and at least in theory temporary.
In the end data model of git is its killer feature because it gives me tools to deal with hard problems and do it efficiently.