Re: git blame and cherry-picking

Steven Grimm [off-list ref] writes:

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

quoted

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