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