All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Thomas Gummerer <t.gummerer@gmail.com>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	git@vger.kernel.org, entwicklung@pengutronix.de
Subject: Re: Regression in v2.23
Date: Tue, 8 Oct 2019 09:49:37 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1910080947070.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1910080932560.46@tvgsbejvaqbjf.bet>

Hi Thomas,

On Tue, 8 Oct 2019, Johannes Schindelin wrote:

> On Mon, 7 Oct 2019, Thomas Gummerer wrote:
>
> > Subject: [PATCH] range-diff: don't segfault with mode-only changes
> >
> > If we don't have a new file, deleted file or renamed file in a diff,
> > we currently add 'patch.new_name' to the range-diff header.  This
> > works well for files that are changed.  However if we have a pure mode
> > change, 'patch.new_name' is NULL, and thus range-diff segfaults.
> >
> > We can however rely on 'patch.def_name' in that case, which is
> > extracted from the 'diff --git' line and should be equal to
> > 'patch.new_name'.  Use that instead to avoid the segfault.
> >
> > Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> > ---
> >  range-diff.c | 20 ++++++++++----------
> >  1 file changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/range-diff.c b/range-diff.c
> > index ba1e9a4265..d8d906b3c6 100644
> > --- a/range-diff.c
> > +++ b/range-diff.c
> > @@ -116,20 +116,20 @@ static int read_patches(const char *range, struct string_list *list)
> >  			if (len < 0)
> >  				die(_("could not parse git header '%.*s'"), (int)len, line);
> >  			strbuf_addstr(&buf, " ## ");
> > -			if (patch.is_new > 0)
> > +			free(current_filename);
> > +			if (patch.is_new > 0) {
> >  				strbuf_addf(&buf, "%s (new)", patch.new_name);
> > -			else if (patch.is_delete > 0)
> > +				current_filename = xstrdup(patch.new_name);
> > +			} else if (patch.is_delete > 0) {
> >  				strbuf_addf(&buf, "%s (deleted)", patch.old_name);
> > -			else if (patch.is_rename)
> > -				strbuf_addf(&buf, "%s => %s", patch.old_name, patch.new_name);
> > -			else
> > -				strbuf_addstr(&buf, patch.new_name);
> > -
> > -			free(current_filename);
> > -			if (patch.is_delete > 0)
> >  				current_filename = xstrdup(patch.old_name);
> > -			else
> > +			} else if (patch.is_rename) {
> > +				strbuf_addf(&buf, "%s => %s", patch.old_name, patch.new_name);
> >  				current_filename = xstrdup(patch.new_name);
> > +			} else {
> > +				strbuf_addstr(&buf, patch.def_name);
> > +				current_filename = xstrdup(patch.def_name);
> > +			}
> >
> >  			if (patch.new_mode && patch.old_mode &&
> >  			    patch.old_mode != patch.new_mode)
> > --
>
> I am not quite sure that this fixes it...

Whoops. I should learn to distrust `git apply` claiming success when
running in `t/`. (I tried to apply your patch, but nothing was actually
applied before I ran `make`.)

So it totally fixes the issue (feel free to just pick up the regression
test case).

Having said that, I would agree with Junio that it'd be nicer to make
`parse_git_diff_header()` more useful to all of its callers, including
future ones.

Sorry for the misreport, and thanks for all the patch,
Dscho

> Here is my regression test case:
>
> -- snipsnap --
> diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
> index ec548654ce1..6aca7f5a5b1 100755
> --- a/t/t3206-range-diff.sh
> +++ b/t/t3206-range-diff.sh
> @@ -354,4 +354,18 @@ test_expect_success 'format-patch --range-diff as commentary' '
>  	grep "> 1: .* new message" 0001-*
>  '
>
> +test_expect_success 'range-diff and mode-only changes' '
> +	git switch -c mode-only &&
> +
> +	test_commit mode-only &&
> +
> +	: pretend it is executable &&
> +	git add --chmod=+x mode-only.t &&
> +	chmod a+x mode-only.t &&
> +	test_tick &&
> +	git commit -m mode-only &&
> +
> +	git range-diff @^...
> +'
> +
>  test_done
>
>
>

  reply	other threads:[~2019-10-08  7:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-07 11:06 Regression in v2.23 Uwe Kleine-König
2019-10-07 13:48 ` Thomas Gummerer
2019-10-08  3:11   ` Junio C Hamano
2019-10-08  7:43     ` Johannes Schindelin
2019-10-08  6:24   ` Uwe Kleine-König
2019-10-08  7:44   ` Johannes Schindelin
2019-10-08  7:49     ` Johannes Schindelin [this message]
2019-10-08 17:38   ` [PATCH v2] range-diff: don't segfault with mode-only changes Thomas Gummerer
2019-10-08 19:44     ` Johannes Schindelin
2019-10-09  7:42     ` Uwe Kleine-König

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.1910080947070.46@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=entwicklung@pengutronix.de \
    --cc=git@vger.kernel.org \
    --cc=t.gummerer@gmail.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /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.