Re: Recording the current branch on each commit?

From: Jeremy Morton <admin@game-point.net>
Date: Apr 27, 2014, 17:38 UTC
Message-ID: <535D4085.4040707@game-point.net>
In-Reply-To: <CALKQrgfmBByMwMhxu3HkJqJGWy2Rwvij6Hi1_4npjfsxcSgpaQ@mail.gmail.com>

On 27/04/2014 10:09, Johan Herland wrote:

Show 12 quoted lines

> On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton<admin@game-point.net>  wrote:
>> Currently, git records a checksum, author, commit date/time, and commit
>> message with every commit (as get be seen from 'git log').  I think it would
>> be useful if, along with the Author and Date, git recorded the name of the
>> current branch on each commit.
>
> This has been discussed multiple times in the past. One example here:
> http://thread.gmane.org/gmane.comp.version-control.git/229422
>
> I believe the current conclusion (if any) is that encoding such
> information as a _structural_ part of the commit object is not useful.
> See the old thread(s) for the actual pro/con arguments.

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. 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.

Show 10 quoted lines

> That said, you are of course free to add this information to your own
> commit messages, by appending something like "Made-on-branch: frotz".
> In a company setting, you can even create a commit message template or
> (prepare-)commit-msg hook to have this line created automatically for
> you and your co-workers. You could even append such information
> retroactively to existing commits with "git notes". There is also the
> current interpret-trailers effort by Christian Couder [1] that should
> be useful in creating and managing such lines.
>
> [1]: http://thread.gmane.org/gmane.comp.version-control.git/245874

Well I guess that's another way of doing it. So, why aren't Author and Date trailers? They don't seem any more fundamental to me than branch name. I mean the only checkin information you really *need* is the checksum, and commit's parents. The Author and Date are just extra pieces of information you might find useful sometimes, right? A bit like some people might find branch checkin name useful sometimes...?

Show 11 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.

> issue in some bug/issue tracker, and it would in any case be natural
> to mention the bug/issue ID in the commit message, at which point the
> tracker can provide more context and discussion.

I think it would only be natural to mention the bug# in the final commit that actually fixes the bug or implements the feature, not the checkins leading up to that. And, it's still not *guaranteed* that the coder will remember to put the bug# in even that commit message.

Show 6 quoted lines

>> Basically,
>> I'm saying that well-named branches can and do carry useful contextual
>> information that oughtn't to be thrown away.  Currently, when you delete
>> that branch, you lose the branch name altogether.
>
> Some would argue that branches are not always well-named... But

But when they are, why should that info be thrown away? When they're not well-named, they can be ignored (or the branch name recording feature can be turned off!)

> anyway, if the branch ends up getting merged to the mainline, the
> merge commit defaults to a message like "Merge branch
> 'pacman-minigame'".

Only if it's a non-ff merge, which results in less tidy commit trees, and hence is often recommended against. 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?

-- 
Best regards,
Jeremy Morton (Jez)