git blame and cherry-picking

What, if any, is the approved way to get git blame to follow cherry- picked changes? Right now blame is good about showing you the actual responsible revision and author in the case of merges, but if you cherry-pick a change with "-n" (to test before committing), the modifications are attributed to the person who did the cherry-pick instead of the cherry-picked revision's author. Even without the "-n" option, the changes are attributed to the cherry-pick *revision* instead of the original one.

My horrible hack workaround for now is to temporarily put a grafts entry in place to make git think the cherry-pick revisions I'm interested in are actually merges. That requires me to know that a given revision is a cherry-pick and I have to be careful to remove my fake graft afterwards. What's more, it can result in some strange and seemingly nonsensical "merge" topologies if, e.g., a newer change is cherry-picked before an older one.

Surely there must be a better way...?

-Steve

Steven Grimm, Thu, Aug 07, 2008 00:18:33 +0200:

The can't be any: cherry-picks are just new commits. You just make the same changes at the new place in the history.

On Thu, Aug 07, 2008 at 08:09:40AM +0200, Alex Riesen wrote:

We used to say "cherry-picked from..." in the commit message, but I don't think we do by default any longer. One could follow that link to see the original change (if it still exists!).

You could potentially have git-blame incorporate that information (again, if the referenced commit is even still available), but I'm not sure exactly what difference it would make. I don't think you would want to start blaming up the original commits line of parentage.

-Peff

On Aug 7, 2008, at 11:22 AM, Jeff King wrote:

No, of course not. But one might want to show the original commit's author instead of the name of the person who did the cherry pick. That's mostly what I'm looking for here; knowing where the change originally came from in terms of the revision graph is occasionally interesting but not nearly as important.

One could argue that the real issue here is that while "git cherry- pick" preserves the original author and doesn't have the misattribution problem, "git cherry-pick -n" discards the original commit's attribution (though it does keep the commit message). Obviously git doesn't necessarily know whether the cherry-picker made substantial changes before committing and should truly be considered the author, but one of the use cases for the "-n" option is a simple "make sure you don't commit totally broken revisions" where there is little to no additional editing of the patch and keeping the original author would support that use case better.

-Steve

Steven Grimm <koreth@midwinter.com> writes:

"cherry-pick" lets you say "-n" so that you can use the change as if you are creating (think of it as a typesaver). You can ask commit to record the result under the original authorship.

Perhaps a workflow sequence would go like this:

    ... Ah, I like that change by Joe; let's see if that really works ...
    $ git cherry-pick -n joe/experimental~4
    $ test test test

    ... Hmm, not quite, let's fix up ...
    $ edit test edit test

    ... Now it works and I like the result, but I'll edit the comment to
    ... describe the change I made on top of what he did to make it work.
    $ git commit -a -c joe/experimental~4

On Thu, Aug 07, 2008 at 11:37:02AM -0700, Steven Grimm wrote:

OK. I think that is a cherry-pick -n issue, then, as you mention below.

I don't think it would be hard to stuff the cherry-picked commit's info somewhere and to pull it out during git-commit. git-am and git-rebase -i are already doing something similar. The harder question is what should be done with multiple "git cherry-pick -n" invocations with different authors?

I haven't looked closely at the git-sequencer stuff, but I wonder if some of this will come with it for free. My impression is that the prototype is built on _top_ of cherry-pick, but that the C version will not be, and that cherry-pick can then be implemented in terms of the sequencer.

-Peff

On 8/6/08, Steven Grimm <koreth@midwinter.com> wrote:

It sounds like you at least want to avoid using "-n", if it really does lose author information that way. If the patch doesn't work, you can always "git commit --amend" or "git reset --hard HEAD^".

I don't think tracing through to the original revision is useful anyway; nothing you'd find through the original commit would be relevant to git blame, AFAICS, since none of those other patches were applied to the branch you're looking at.

Have fun,

Avery