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