git blame and cherry-picking

git blame and cherry-picking

[Steven Grimm]

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

Re: git blame and cherry-picking

[Alex Riesen]

Steven Grimm, Thu, Aug 07, 2008 00:18:33 +0200:
> What, if any, is the approved way to get git blame to follow cherry- 
> picked changes?

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

Re: git blame and cherry-picking

[Avery Pennarun]

On 8/6/08, Steven Grimm <koreth@midwinter.com> wrote:
> 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.

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

Re: git blame and cherry-picking

[Jeff King]

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

> Steven Grimm, Thu, Aug 07, 2008 00:18:33 +0200:
> > What, if any, is the approved way to get git blame to follow cherry- 
> > picked changes?
> 
> The can't be any: cherry-picks are just new commits. You just make the
> same changes at the new place in the history.

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

Re: git blame and cherry-picking

[Steven Grimm]

On Aug 7, 2008, at 11:22 AM, Jeff King wrote:
> 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.

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

Re: git blame and cherry-picking

[Junio C Hamano]

Steven Grimm <koreth@midwinter.com> writes:

> On Aug 7, 2008, at 11:22 AM, Jeff King wrote:
>> 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.
>
> 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.

"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

Re: git blame and cherry-picking

[Jeff King]

On Thu, Aug 07, 2008 at 11:37:02AM -0700, Steven Grimm 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.

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

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

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