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:08 UTC
- Message-ID
- <xmqqa82ygggp.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20170817084109.ba7g2hnymtwqeclw@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> [+cc Junio, as this gets deep into git-apply innards]
I've written off --recount and --allow-overlap as ugly workaround that happens to work some of the time but cannot be trusted long time ago.
IIRC, before the "(e)dit" thing was added to "add -p", we counted the line numbers correctly and merged the adjacent hunks before applying and neither of these two kluge was necessary.
These threads may give us a bit more background:
https://public-inbox.org/git/7viqk1ndlk.fsf@alter.siamese.dyndns.org/ https://public-inbox.org/git/1304117373-592-1-git-send-email-gitster@pobox.com/
The original that introduced the "(e)dit" thing was in this thread:
https://public-inbox.org/git/200805232221.45406.trast@student.ethz.ch/
As you can see, I was very much against it, as it cannot fundamentally sanely implemented (which I think is the same conclusion you reached at the end of the current thread).
I think there should be a better failure mode, though.