All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH 7/7] apply --allow-overlap: fix a corner case
Date: Fri, 6 Dec 2019 15:11:41 +0100 (CET)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1912061502110.31080@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <xmqqr21hy3cf.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Fri, 6 Dec 2019, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > Yes, yes, this is supposed to be only a band-aid option for `git add -p`
> > not Doing The Right Thing. But as long as we carry the `--allow-overlap`
> > option, we might just as well get it right.
>
> It probably depends on the definition of "right", where it may not
> even exist (otherwise it wouldn't be a band-aid but be a real
> feature) ;-)

Indeed. My hope is that we can get rid of it once the scripted
`git-add--interactive.perl` is removed in favor of the built-in add -i/-p.
This is a long way off, of course.

> > This fixes the case where one hunk inserts a line before the first line,
> > and is followed by a hunk whose context overlaps with the first one's
> > and which appends a line at the end.
>
> The in-code comment makes me wonder if we need to further loosen the
> check in the other direction, though.  What makes begin more special
> than end?  Can a hunk be seen that pretends to extend to the end but
> no longer does because there was an overlapping hunk that has been
> wiggled in?

The beginning is more special than the end because it is associated with
the line number 1. The end line number is flexible already.

There is another difference: after splitting hunks, the first hunk is
applied first, and may render the line numbers of succeeding hunks
incorrect. The same is not true for the last hunk: it cannot render the
preceding hunks' line numbers incorrect, as it has not been applied yet.

I think that's why `--allow-overlap` works with this patch when adding
lines both to the beginning and to the end after splitting a single hunk.

Ciao,
Dscho

> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  apply.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/apply.c b/apply.c
> > index f8a046a6a5..720a631eaa 100644
> > --- a/apply.c
> > +++ b/apply.c
> > @@ -2661,6 +2661,16 @@ static int find_pos(struct apply_state *state,
> >  	unsigned long backwards, forwards, current;
> >  	int backwards_lno, forwards_lno, current_lno;
> >
> > +	/*
> > +	 * When running with --allow-overlap, it is possible that a hunk is
> > +	 * seen that pretends to start at the beginning (but no longer does),
> > +	 * and that *still* needs to match the end. So trust `match_end` more
> > +	 * than `match_beginning`.
> > +	 */
> > +	if (state->allow_overlap && match_beginning && match_end &&
> > +	    img->nr - preimage->nr != 0)
> > +		match_beginning = 0;
> > +
> >  	/*
> >  	 * If match_beginning or match_end is specified, there is no
> >  	 * point starting from a wrong line that will never match and
>

  reply	other threads:[~2019-12-06 14:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-06 13:08 [PATCH 0/7] add -i: close some regression test gaps Johannes Schindelin via GitGitGadget
2019-12-06 13:08 ` [PATCH 1/7] t3701: add a test for advanced split-hunk editing Johannes Schindelin via GitGitGadget
2019-12-06 13:08 ` [PATCH 2/7] t3701: avoid depending on the TTY prerequisite Johannes Schindelin via GitGitGadget
2019-12-16 12:18   ` SZEDER Gábor
2019-12-17  5:53     ` Jeff King
2019-12-06 13:08 ` [PATCH 3/7] t3701: add a test for the different `add -p` prompts Johannes Schindelin via GitGitGadget
2019-12-06 13:08 ` [PATCH 4/7] t3701: verify the shown messages when nothing can be added Johannes Schindelin via GitGitGadget
2019-12-06 13:08 ` [PATCH 5/7] t3701: verify that the diff.algorithm config setting is handled Johannes Schindelin via GitGitGadget
2019-12-06 13:08 ` [PATCH 6/7] git add -p: use non-zero exit code when the diff generation failed Johannes Schindelin via GitGitGadget
2019-12-06 20:48   ` Junio C Hamano
2019-12-06 13:08 ` [PATCH 7/7] apply --allow-overlap: fix a corner case Johannes Schindelin via GitGitGadget
2019-12-06 13:45   ` Junio C Hamano
2019-12-06 14:11     ` Johannes Schindelin [this message]
2019-12-06 16:40       ` Junio C Hamano
2019-12-06 17:56         ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1912061502110.31080@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.