On Wed, Jun 27, 2012 at 02:02:34PM -0700, Junio C Hamano wrote: > Thanks. > > We recently had a topic to add an option to allow rebase to carry > empty commits forward, but I notice that it only had tests for the > component cherry-pick to keep empty or redundant commits, so it may > not be a bad idea to add tests for that series to the same t3401 > after this commit (Neil Horman CC'ed). > > 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? 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