Re: git blame and cherry-picking
- From
Steven Grimm <koreth@midwinter.com>
- Date
- Aug 7, 2008, 18:37 UTC
- Message-ID
- <AA6BDC98-8800-4031-8C8F-A4BD326BEC1E@midwinter.com>
- In-Reply-To
- <20080807182256.GF11314@sigill.intra.peff.net>
On Aug 7, 2008, at 11:22 AM, Jeff King wrote:
Show 5 quoted lines
> 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