Re: Recording the current branch on each commit?

From: Jeremy Morton <admin@game-point.net>
Date: Apr 27, 2014, 20:55 UTC
Message-ID: <535D6EB1.9080208@game-point.net>
In-Reply-To: <CALKQrgemFx=2JaC1BaRqCwEV+knC8QftxcZ7K0AsT9azzuyVdA@mail.gmail.com>

On 27/04/2014 20:33, Johan Herland wrote:

Show 17 quoted lines

> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton<admin@game-point.net>  wrote:
>> On 27/04/2014 10:09, Johan Herland wrote:
>> As far as I can tell from that discussion, the general opposition to
>> encoding the branch name as a structural part of the commit object is that,
>> for some people's workflows, it would be unhelpful and/or misleading. Well
>> fair enough then - why don't we make it a setting that is off by default,
>> and can easily be switched on?  That way the people for whom tagging the
>> branch name would be useful have a very easy way to switch it on.
>
> Therefore, the most pragmatic and constructive thing to do at this
> point, is IMHO to work within the confines of the existing commit
> object structure. I actually believe using commit message trailers
> like "Made-on-branch: frotz" in addition to some helpful
> infrastructure (hooks, templates, git-interpret-trailers, etc.) should
> get you pretty much exactly what you want. And if this feature turns
> out to be extremely useful for a lot of users, we can certainly
> consider changing the commit object format in the future.

OK, fair enough. So I guess what I'd like to see, then, is good built-in functionality in Git for these commit message trailers, so that they are very easy to turn on. I'd like to be able to tell co-developers to add a one-liner to their git config file rather than some post-commit script.

Show 12 quoted lines

>> I know
>> that for the workflows I personally have used in the past, such tagging
>> would be very useful.  Quite often I have been looking through the Git log
>> and wondered what feature a commit was "part of", because I have feature
>> branches.  Just knowing that branch name would be really useful, but the
>> branch has since been deleted... and in the case of a ff-merge (which I
>> thought was recommended in Git if possible), the branch name is completely
>> gone.
>
> True. The branch name is - for better or worse - simply not considered
> very important by Git, and a Git commit is simply not considered (by
> Git at least) to "be part of" or otherwise "belong to" any branch.

Please understand that I know this full well. :-) I'm saying that the 'ephemeral' pointers' names are, in themselves, useful - if, like me, you give them meaningful names. What I'm proposing is pretty much an automatic tagging (somehow...) of each commit with the current branch name (if one is available); information that carries roughly the same weight as the commit message. It could be crap, but equally it could be very useful, in some workflows. I think most of us can agree on that.

> seems to only have come up a few times on the mailing list. This is

But it has come up more than once, which would seem to indicate that I'm not the only one with this request. ;-)

> IINM, Mercurial does this differently, so that may be a better fit for

"If I'm Not Mistaken" - I had to look that one up.

> the workflows where keeping track of branch names is very important.

Nah, I had a look at Mercurial and I think I prefer Git - this branch name thing is just my one bugbear. I definitely prefer Git's concept of a staging area rather than just committing all changes. To do that in Mercurial you have to use mq and all the different (IMHO unintuative) commands that entails, and if you accidentally "mq commit" then you screw everything up. :-) Mercurial also discourages history rewriting (ie. cleaning up of messy commits), which Git doesn't. I prefer Git's approach here too.

Show 9 quoted lines

> Yeah, sure. Author and Date (and Committer, for that matter) is just
> metadata, and the current branch name is simply just another kind of
> metadata. All of them are more-or-less free-form text fields, and off
> the top of my head, I can't really say that if we were to design Git
> from scratch today, they wouldn't all become optional trailers (or
> headers, or what-have-you).
>
> However, we're not designing Git from scratch, and we have to work
> with what is already there...

Fair point.

Show 22 quoted lines

>>>> The branch name can provide useful
>>>> contextual information.  For instance, let's say I'm developing a suite
>>>> of
>>>> games.  If the commit message says "Added basic options dialog", it might
>>>> be
>>>> useful to see that the branch name is "pacman-minigame" indicating that
>>>> the
>>>> commit pertains to the options dialog in the Pacman minigame.
>>>
>>> In that partcular case, ISTM that the context ("pacman-minigame")
>>> would actually be better preserved elsewhere. E.g. the commits touch
>>> files in a particular "minigames/pacman" subdir, or you prefix the
>>> context in the commit message ("pacman-minigame: Added basic options
>>> dialog"). Also, such a "topic" branch is often tied to a specific
>>
>> Again, this is a pain because you have to remember to manually tag every
>> commit message with "pacman-minigame", and it takes up precious space in the
>> (already short) commit message.
>
> Yes, which is why I advise you to look at commit message templates,
> hooks, and interpret-trailers to see if you can find a way to automate
> this for you and your co-workers.

What I'd like to see, then, is this trailer functionality built in to Git so that a very minimal amount of setup is needed to get everybody using it. We're basically talking about hijacking the commit messages and tacking on information that they weren't really intended to hold (ie. stuff the developer hasn't manually typed in as a commit message), because of the limitation of the Git commit format. In hindsight, I guess it would've been better to have the Git commit format be more flexible in terms of what headers it allows, so that new headers could easily be added and some headers could be optional.

Show 10 quoted lines

>> Only if it's a non-ff merge, which results in less tidy commit trees, and
>> hence is often recommended against.
>
> Not at all. If you're developing a series of commits with a common
> purpose (a.k.a. a topic branch) I would very much argue for
> non-ff-merging this, _exactly_ because the merge commit allows you to
> introduce the entire topic as a single entity. The merge commit
> message (in addition to containing the branch name) is also the
> natural place to describe more general things about the topic as a
> whole - sort of like the cover letter to a patch series.

Would you recommend that every single commit be made in a branch that gets merged into master, then? So, no direct commits to master?

Show 11 quoted lines

> The problem is not really "less tidy commit trees" - by which I gather
> you mean history graphs that are non-linear. IMHO, the history graph
> should reflect parallel/branched development when that is useful.
> Blindly rebasing everything into a single line is IMHO just as bad as
> doing all your work directly on master and blindly running "git pull"
> between each of your own commits (which results in a lot of useless
> merges). The merge commits themselves are not the problem. Merge
> commits are a tool, and when used properly (to introduce topics to the
> master branch like described above) they are a good tool. When abused
> (like blindly running "git pull" and accepting useless "merge
> bubbles") they create more problems than they solve.

Sounds like the default behaviour of "git pull" might not be ideal if it easily causes these problems.

Show 9 quoted lines

>>   Whatsmore, tracking down which branch a
>> commit pertains to is still rather difficult using this approach.  You can
>> go back through the history and find "Merge branch 'pacman-minigame'", but
>> how do you know which commit was the *start* of that branch, if they are not
>> tagged with the branch name?
>
> Once you have found the merge commit (M), git log M^1..M^2 should list
> all the commits that were made on that branch. The parent of the last
> in that list can be considered the starting point for the branch.

I don't quite understand this; your suggestion would only work on the assumption that no merges have been made from master to that branch; git log M^1..M^2 will get the most recent common ancestor of the two and show the commits between them, but if there has been a merge from master to branch, it will not show the commits to the branch before that merge... so it's not as useful as tagging. You'd have to do some work to get all the branch's commits, which is rather undesirable when you could just see the branch name (when perusing 'git log') if it were tagged as part of the commit.

> Hope this helps,
>
> ...Johan

-- 
Best regards,
Jeremy Morton (Jez)