On Tue, Jul 03, 2012 at 12:00:27PM -0700, Junio C Hamano wrote: > Neil Horman <nhorman@xxxxxxxxxxxxx> writes: > > > So, I've been thinking about this some, and I'm a bit stuck on it. Reading the > > test description for t3401, I see that we're testing gits ability to detect > > patches merged upstream when doing a rebase. That said, how are we supposed to > > differentiate between upstream empty patches that have been cherry-picked or > > merged, and local branch empty changes that haven't. As humans we can see that > > the changelog might be the same, but git has no way to detect that, and if > > --allow-empty is specified will just apply any empty patch it finds between the > > two branches merge base and the topic branch head. Does anyone have an idea as > > to how we should detect such duplication? > > The changelog might be similar or textually identical, but it is > entirely a different matter if it makes sense taken out of the > context (i.e. cherry-picked). So I would personally do not bother > "filtering" about them too much---if you ask for empties, you will > get all empties. > Ok, copy that. Thanks! Neil -- 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