Re: [PATCH] add test case for rebase of empty commit
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 3, 2012, 19:00 UTC
- Message-ID
- <7vtxxovfec.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20120703182000.GB10864@hmsreliant.think-freely.org>
Neil Horman <nhorman@tuxdriver.com> writes:
Show 9 quoted lines
> 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.