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.

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

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

> 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
anyway, if the branch ends up getting merged to the mainline, the
merge commit defaults to a message like "Merge branch

> So what do you think?  Would it be good to have a patch to add this feature?

One is free to try, of course, but I wouldn't get my hopes up for a
patch that changes the fundamental format of the commit object to
include something that many users/workflows would consider to be pure

If you still believe that this is useful enough to warrant a change to
the commit object format, it is probably better to start off putting
the information in the commit message (as described above), and
provide some tools that demonstrate the added value of this
information. If that is successful and gains momentum, the git
community can certainly reconsider whether it makes sense to fold it
into a more formalized part of the commit object.


Johan Herland, <jo...@herland.net>
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