RE: rationale behind git not tracking history of branches

["Randall S. Becker" <rsbecker@nexbridge.com>]

On May 26, 2020 5:01 PM, Kevin Buchs wrote:
> For many years of using Git, I always struggled to make sense of commit
> history graphs (git log --graph; gitk). Just recently I discovered that git does
> not track the history of branches to which commits belonged and the
> lightbulb turned on. This is proving to be painful in a project I inherited with
> permanent multiple branches.
> Now, I am a bit curious as to the rationale behind this intentional decision
> not to track branch history. Is it entirely a matter of keeping branches
> lightweight?
> 
> I am assuming one can backfill for the missing capability by using a commit
> hook to manually track when a branch head is changed. Perhaps by storing
> the branch in the commit notes.

Based on the distributed nature of git, the interpretation of the history of a branch can be different based on local clones. The history only comes together as commits are merged together on an upstream repository, so even in the upstream, the interpretation is potentially different from what the branch's interpretation is in someone's clone. The parent-child commit structure in the underlying Merkel tree is the only definitive interpretation and is a post-merge perspective independent of any interpretation of the branch itself.

The point-in-time interpretation of a branch is simply the HEAD where the branch pointer is located, but the point-in-time interpretation is ambiguous across multiple clones and even the upstream. In order to disambiguate the interpretation, the branch contents have to be moved to a common repository which only understands its branch HEAD post push, which may be disallowed without a merge depending on the current tree structure.

To track a branch's history across all domains, and make it meaningful, you could write a commit, push, etc. hook, that understands what the current state of the branch is and where, and interpret the history based on your own project needs. It would be something like a relation set something like the tuple: {some-unique-repo-clone-identifier; branch; commit; date-and-time}, as the branch state (HEAD) is time-varying and can repeat its presence on a commit multiple times (git branch -f branch-name commit-ish) . The "some-unique-repo-clone-identifier" is problematic, because there isn't one currently AFAIK.

That's my interpretation anyway based on how I see things in today's git world - I might very well be wrong.

Regards,
Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.