list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Philip Oakley" <>
To: "Junio C Hamano" <>, "Ed Hutchins" <>
Cc: "Matthieu Moy" <>,
	"Git List" <>
Subject: Re: Feature request: "author branch" in commit object
Date: Tue, 9 Jul 2013 22:46:36 +0100	[thread overview]
Message-ID: <E66A4CB66EF64CE5A46851045BFB48FA@PhilipOakley> (raw)
In-Reply-To: <>

From: "Junio C Hamano" <>
Sent: Wednesday, July 03, 2013 7:08 PM
[catching up on old emails]
> Ed Hutchins <> writes:
>> I'm not trying to change the way git does things (which works
>> perfectly
>> well), I'm asking for some extra information to be added to the
>> commit
>> so that analysis of the ancestry graph can be tied to the branch
>> topics
>> that the original author was working from. Currently if you have a
>> rebase-branch/ff-merge-to-master workflow, the graph of commits looks
>> like a single user produced all of the code. It would be very useful
>> for
>> both forensic and display purposes to categorize those commits by
>> their
>> original topics, but that history is lost in such a workflow.
> I am not following that "a single user" part. As long as these
> topics are done by different people, the authorship remains
> separate, no matter what the shape of the graph is.
> It all depends on what you show on the graph other than a circle and
> connecting lines, but I presume at least you would show the subject
> line. The graph would clearly show which groups of commits tackle
> what problems in your history, even if you excessively linearlized
> it by rebasing. You need subjects / commit log messages that are
> better than "bugfix", of course, for it to work, though.
>> Arguing that branch names are local and thus meaningless misses
>> the point: branches are *names* which were meaningful to the
>> author at the time the branch was being worked on.
> That is not necessarily true.
> Most of my commits start their life on a single branch that is named
> after a very broad theme (or even on a detached HEAD) that ends up
> touching different parts of the system and then later split into
> separate topic branches that are named after more detailed single
> issues. The name of the branch that happened to have been used to
> create them have almost no meaning after I am done with multiple and
> independent (but related in the larger scheme of things) topics.
> It is not just misleading but is actively wrong to recording the
> name of the original branch in commits and carrying them forward via
> rebase. If you want a record of what a group of commits were about,
> the right time to do so is when you merge.

While the general arguments are true that in the main one shouldn't
embed whatever random branch name was used into the commit messages,
there are some workflows and some production (corporate) environments
where adding a relevant branch name is suitable for that environment.

If the existing branch name is poor then the user should do a rebase to
transfer it to a better branch name, and then the 'git filter-branch'
command would be the obvious method to add a "Developed-on: <branch>"
final 'signoff line'.

The 'git filter-branch' man page already includes an example for adding
an acked by, which can easily be modified.

If you need to add Acked-by lines to, say, the last 10 commits (none of
which is a merge), use this command:

git filter-branch --msg-filter '
        cat &&
        echo "Acked-by: Bugs Bunny <>"

I'll leave it to Ed to automate it as a script.... (and possibly making 
sure it's idempotent so only the final branch name is retained, etc.)

> Projects that care about the shape of the ancestry graph have an
> obvious option of not excessively/unnecessarily linearlizing their
> history. We even have the "--no-ff" mode of merge to create an
> otherwise unnecessary merge to mark the point where a topic is
> merged to the mainline, so that merge log messages can say what
> topic was merged (and also you can even have "merge.log").
> Cleaning up a messy history created on a topic branch before
> presenting to others by lineralizing is one thing. It is a good
> practice. Requiring any update to fast-forward on top of the tip of
> the project is quite different. It does not make your history any
> easier to read. A topic that has been working fine on top of last
> week's trunk can have a subtle interaction with the work done by
> others on the trunk since it forked, and rebasing it on top of
> today's trunk, just before pushing it out on the trunk, risks
> breaking the topic in a subtle way without the person who does such
> a rebase without noticing, making later bisection harder.
> Any option to encourage such an artificially linear history _is_
> actively detrimental.
> --

The boss may not always be right, but she is the boss. 

      parent reply	other threads:[~2013-07-09 21:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-02 19:37 Ed Hutchins
2013-07-02 19:49 ` Fredrik Gustafsson
2013-07-02 20:00 ` Junio C Hamano
2013-07-02 20:34   ` Ed Hutchins
2013-07-03 16:16     ` Antoine Pelisse
2013-07-03 17:31       ` Ed Hutchins
2013-07-03 18:19         ` Junio C Hamano
2013-07-04  0:00           ` Andrew Ardill
2013-07-02 20:31 ` Johan Herland
2013-07-03  9:33 ` Matthieu Moy
2013-07-03 15:47   ` Ed Hutchins
2013-07-03 18:08     ` Junio C Hamano
2013-07-03 23:46       ` Feature request: Jakub Narebski
2013-07-03 23:52         ` Dany
2013-07-03 23:53           ` Dany
2013-07-04  8:08             ` Matthieu Moy
2013-07-09 21:46       ` Philip Oakley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E66A4CB66EF64CE5A46851045BFB48FA@PhilipOakley \ \ \ \ \ \
    --subject='Re: Feature request: "author branch" in commit object' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).