Re: rationale behind git not tracking history of branches

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

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.

I think this comes down to a question of mental model: one thing I
value when using Git is that each commit does *not* belong to a
specific branch --- branches describe the shape of history, and
commits are points in that history.

This becomes particularly relevant when working with multiple
colleagues, sharing history between different servers: I may have a
branch I call "linus" that points to the same history that a colleague
called "master".

That said, I can understand how that may be difficult to get used to
coming from other version control systems (such as Subversion) in
which a revision does belong to a branch.

Can you say a little more about what aim you're trying to achieve when
you want to make this lookup?  For example:

- are you looking to figure out what the commit author was working
  on when they made the commit?  For that, the commit message is meant
  to provide context, and a commit hook like you describe can be a
  good way to enforce that (for example if you want every commit
  message to contain a bug number for context).

- are you looking to find out *when* a commit became part of a
  particular published branch?  It's true that Git doesn't provide a
  good way to do that today.  I have some hope that some best
  practices like discussed in [1][2] will coalesce for attesting to
  the history of a branch's state.

  If you always perform merges with --no-ff, then you can find some
  things out using the --first-parent history.  It is possible to
  enforce such practices using hooks, but this may be a lot of fuss
  for little gain, depending on the underlying need.

  I find "git log --ancestry-path" to be very useful for finding out
  *how* a commit became part of a particular published branch.

- or are you looking for this information for some other purpose?

Returning to your question: one reason that I find Git not recording
the current branch name to be liberating is that I am not great at
naming things.  I can use a placeholder name, knowing that I am its
only audience, without fear of embarrassment.

Thanks and hope that helps,
Jonathan

[1] https://git.eclipse.org/r/c/51128, describing refs/meta/push-certs
[2] https://lore.kernel.org/git/22945.15202.337224.529980@chiark.greenend.org.uk/