Re: rationale behind git not tracking history of branches

[Kevin Buchs <kevin.buchs@newcontext.com>]

Hi Jonathan,

Thanks for the reply. I will give you my current situation. I am just
taking over a project that many cooks were involved in previously. We
have three persistent branches: dev, staging and master which
correspond directly to three CD environments: dev, staging and prod.
The nominal commit history ought to be that all changes happen in the
dev branch, and that the latest dev is merged into staging and then to
master at appropriate milestones of testing. However, the history of
commit chains clearly show that is not the case. Here is what gitk
shows me: https://1drv.ms/u/s!AgKA2HL-SveIha4Y_5lihkQO7ulfKQ?e=oA9PEi
.
Now, you can see that the nominal practice was not followed. Sure,
there are many commit messages to indicate merges and I could assume
those are correct and possibly reconstruct which branch each commit
might have belonged to. However, you can see there were a series of
changes to multiple commit chains, when there should have just been a
single chain - corresponding to the dev branch. How do I know there
were not changes that should be included in dev that were stranded?
Based on the overall "smell" of this project, I really don't believe I
should trust those commit messages. So, what would make my task a
whole lot easier would be if there were a display of columns
corresponding to the branches and any commits that were in multiple
branches, due to merge fast forwarding, would explicitly show up in
the corresponding columns.

Going forward, I believe I can make my own work much clearer for
others who might pick it up by having some way to sort out branch
history. I will probably use --no-ff to make history clearer. And
maybe notes to actually record to which branch a commit belongs.

I had been studying this Q&A:
https://stackoverflow.com/questions/2706797/finding-what-branch-a-git-commit-came-from
. I have come to realize the only item that is really useful there is
the first comment on the question. It says that the lack of recording
of branch history in git is "by design". I understand the point of
making branches lightweight. though I don't know that recording a
branch would make them much heavier. I wondered if there was another
motivation in the design of git. Knowing that might help me to use the
tool more effectively or adapt it to where I would like it to be.

Kevin Buchs, Senior Engineer, New Context Services
kevin.buchs@newcontext.com  507-251-7463  St. Cloud, MN

Kevin Buchs, Senior Engineer, New Context Services
kevin.buchs@newcontext.com  507-251-7463  St. Cloud, MN


On Tue, May 26, 2020 at 9:50 PM Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> 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/