From: Jonathan Nieder <jrnieder@gmail.com>
To: Kevin Buchs <kevin.buchs@newcontext.com>
Cc: git@vger.kernel.org
Subject: Re: rationale behind git not tracking history of branches
Date: Tue, 26 May 2020 19:50:48 -0700 [thread overview]
Message-ID: <20200527025048.GC172669@google.com> (raw)
In-Reply-To: <CAKTRx=09tjsH0j+Nf4_1uzn-GwasWFB_Q96KEO=qtr5nVBkAew@mail.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/
next prev parent reply other threads:[~2020-05-27 2:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-26 21:01 rationale behind git not tracking history of branches Kevin Buchs
2020-05-27 2:50 ` Jonathan Nieder [this message]
2020-05-27 16:24 ` Kevin Buchs
2020-05-27 19:31 ` Michal Suchánek
2020-05-27 16:10 ` Randall S. Becker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200527025048.GC172669@google.com \
--to=jrnieder@gmail.com \
--cc=git@vger.kernel.org \
--cc=kevin.buchs@newcontext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).