Linus Torvalds wrote: > > On Fri, 12 Sep 2008, Sam Vilain wrote: >> 2. make git-cherry-pick have a similar option to '-x', but instead of >> recording the original commit ID, record the original *patch* ID, >> *if* there was a merge conflict for that cherry pick. > > Actually, don't make it dependent on merge conflicts. Just make it depend > on whether the patch ID is _different_. > > It can happen even without any conflicts, just because the context > changed. So it really isn't about merge conflicts per se, just the fact > that a patch can change when it is applied in a new area with a three-way > diff - or because it got applied with fuzz. > > You could add it as a > > Original-patch-id: <sha1> > > or something. And then you just need to teach "git cherry/rebase" to take > both the original ID and the new one into account when deciding whether it > has already seen that patch. Yes, right - it's the patch ID changing that's the problem for git-cherry / rev-list --cherry-pick to be able to spot changes as the 'same'. Someone else pointed out that git-rebase -i might want to have this as well. I actually looked into coding this, but there was a little problem with the way git-revert worked - it builds the commit message before the diff is calculated. So there would probably need to be a little trivial refactoring first before this can be implemented. Sam. -- 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
