Jeff King <p...@peff.net> writes:
> On Wed, May 29, 2013 at 11:08:46AM -0700, Junio C Hamano wrote:
>> This has rather interesting ramifications on cherry-pick and rebase,
>> though. Both command can handle changes that come from an old tree
>> before some paths were renamed, but strict patch-id would not spot
>> equivalent changes we already have in our history if our change
>> happened after a rename, i.e.
>> where Z updates path F, R moves F to G and X changes G the same way
>> as Z changes F, and we are trying to cherry-pick Z on top of Y. The
>> cherry-pick filter will see different patch-id for Z and X.
> True. That is a problem with the current patch-id system, no?
Correct. That is why I suggested not to change the external
interface (i.e. what is shown from patch-id command) as people may
have kept them, but wondered if a possible improvement may be to
exclude the name from ids when we internally generate two sets of
Ids and intersect them, i.e. log --cherry.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html