On 27/04/2014 10:09, Johan Herland wrote:
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton<ad...@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:

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.

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

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.

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

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)
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to