On 27/04/2014 10:09, Johan Herland wrote:
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton<admin@xxxxxxxxxxxxxx> 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.
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.
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)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html