Re: git add -p breaks after split on change at the top of the file

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 17, 2017, 19:22 UTC
Message-ID: <xmqq60dmgftg.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170817091503.vsd4lncogphy5gxx@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> Of course this is a pretty ridiculous input in the first place. In
> theory it _could_ be figured out, but overlapping hunks like this are
> always going to cause problems (in this case, context from the second
> hunk became a removal, and the second hunk no longer applies).

To be honest, I do not think it could be figured out by "git apply", but "git add -p" _should_ be able to. I've said already this earlier in the discussion:

  https://public-inbox.org/git/7vab5cn7wr.fsf@alter.siamese.dyndns.org/

"add -p" knows how the hunk _before_ it gave the user to edit looked like, and it knows how the hunk after the user edited looks like, so it may have enough information to figure it out. But the "(e)dit" feature was done in a way to discard that information and forced an impossible "guess what the correct shape of the patch would be, out of this broken patch input" with --recount and --allow-overlap.

If we want to make "add -p/(e)dit" work in the corner cases and make it trustworthy, "apply" is a wrong tree to back at. A major part of the effort to fix would go to "add -p", not to "apply".