Steven Grimm <koreth@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
