git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Johannes Sixt <j.sixt@viscovery.net>, git@vger.kernel.org
Subject: Re: [PATCH v3 1/2] Allow git-apply to ignore the hunk headers (AKA recountdiff)
Date: Thu, 05 Jun 2008 21:55:08 -0700	[thread overview]
Message-ID: <7vve0nw4b7.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.DEB.1.00.0806060006370.21190@racer> (Johannes Schindelin's message of "Fri, 6 Jun 2008 00:06:50 +0100 (BST)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> +static int recount_diff(char *line, int size, struct fragment *fragment)
> +{
> +	int line_nr = 0;

At this point, line points at the beginning of the line that immediately
follows "@@ -oldpos,oldlines +newpos,newlines @@ ...\n", right?

> +	if (size < 1)
> +		return -1;
> +
> +	fragment->oldpos = 2;

Why do you discard oldpos information, and use magic number "2"?

> +	fragment->oldlines = fragment->newlines = 0;
> +
> +	for (;;) {
> +		int len = linelen(line, size);
> +		size -= len;
> +		line += len;

And you look at the line of the patch, measure how long it is, and you
already advance line to point at the next line without ever looking at the
contents of the line (you could look at line[-len], but that is crazy).

> +		if (size < 1)
> +			return 0;

Why?  It may be the last line in the hunk but you haven't done anything to
the current line yet.

> +		switch (*line) {
> +		case ' ': case '\n':
> +			fragment->newlines++;
> +			/* fall through */
> +		case '-':
> +			fragment->oldlines++;
> +			break;
> +		case '+':
> +			fragment->newlines++;
> +			if (line_nr == 0) {
> +				fragment->leading = 1;
> +				fragment->oldpos = 1;
> +			}
> +			fragment->trailing = 1;

Again, why muck with oldpos?  Also leading and trailing?  After you
recount the newlines and oldlines you ignored from the hunk header, the
caller will behave as if the original patch had the right numbers on the
hunk header to compute leading and trailing, doesn't it?

> +			break;
> +		case '@':
> +			return size < 3 || prefixcmp(line, "@@ ");
> +		case 'd':
> +			return size < 5 || prefixcmp(line, "diff ");
> +		default:
> +			return -1;

I do not understand these return values.  Your caller, parse_fragment()
with your patch, gives you chance to recount the old and new line count,
and you are responsible for only recounting them.  The change you made to
parse_fragment() returns error, aborting the whole git-apply, when
recount_diff() returns non-zero, but having extra lines after the patch
text is perfectly fine and there is no reason to force aborting from
here.  IOW, this function should not even have power to do so.  The one
and only thing this function should do well is to reliably count the
number of patch lines.

> @@ -1013,6 +1058,9 @@ static int parse_fragment(char *line, unsigned long size,
>  	offset = parse_fragment_header(line, len, fragment);
>  	if (offset < 0)
>  		return -1;
> +	if (offset > 0 && patch->recount &&
> +			recount_diff(line + offset, size - offset, fragment))
> +		return -1;

... and this "return -1" is uncalled for.

  reply	other threads:[~2008-06-06  4:56 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-05 10:16 [PATCH 1/2] Allow git-apply to fix up the line counts Johannes Schindelin
2008-06-05 10:17 ` [PATCH 2/2] git-add: introduce --edit (to edit the diff vs. the index) Johannes Schindelin
2008-06-05 11:24 ` [PATCH 1/2] Allow git-apply to fix up the line counts Johannes Sixt
2008-06-05 13:04   ` Johannes Schindelin
2008-06-05 13:36     ` Johannes Sixt
2008-06-05 13:47       ` Johannes Schindelin
2008-06-05 14:13         ` Johannes Sixt
2008-06-05 14:54           ` Johannes Schindelin
2008-06-05 15:07             ` Johannes Sixt
2008-06-05 16:19               ` [PATCH v2 0/2] git add --edit Johannes Schindelin
2008-06-05 16:20                 ` [PATCH v2 1/2] Allow git-apply to ignore the hunk headers Johannes Schindelin
2008-06-05 21:16                   ` Junio C Hamano
2008-06-05 22:39                     ` Johannes Schindelin
2008-06-05 23:06                       ` [PATCH v3 0/2] git add --edit Johannes Schindelin
2008-06-05 23:06                         ` [PATCH v3 1/2] Allow git-apply to ignore the hunk headers (AKA recountdiff) Johannes Schindelin
2008-06-06  4:55                           ` Junio C Hamano [this message]
2008-06-06 13:58                             ` Johannes Schindelin
2008-06-06 15:34                               ` Junio C Hamano
2008-06-06 16:13                               ` Junio C Hamano
2008-06-06 16:37                                 ` Johannes Schindelin
2008-06-06 16:46                                   ` Junio C Hamano
2008-06-06 17:35                                     ` Johannes Schindelin
2008-06-06  5:18                           ` Govind Salinas
2008-06-06 14:00                             ` Johannes Schindelin
2008-06-05 23:07                         ` [PATCH v3 2/2] git-add: introduce --edit (to edit the diff vs. the index) Johannes Schindelin
2008-06-06 10:02                           ` Olivier Marin
2008-06-06 14:21                             ` Johannes Schindelin
2008-06-06  4:55                         ` [PATCH v3 0/2] git add --edit Junio C Hamano
2008-06-06 13:59                           ` Johannes Schindelin
2008-06-05 23:22                       ` [PATCH v2 1/2] Allow git-apply to ignore the hunk headers Junio C Hamano
2008-06-05 23:36                         ` Johannes Schindelin
2008-06-06  7:02                           ` Paolo Bonzini
2008-06-06 14:04                             ` Johannes Schindelin
2008-06-06 10:33                         ` Sergei Organov
2008-06-06 14:27                           ` Johannes Schindelin
2008-06-06 15:14                           ` Junio C Hamano
2008-06-05 16:20                 ` [PATCH v2 2/2] git-add: introduce --edit (to edit the diff vs. the index) Johannes Schindelin
2008-06-05 18:12                   ` Pieter de Bie
2008-06-05 18:39         ` [PATCH 1/2] Allow git-apply to fix up the line counts Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=7vve0nw4b7.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=j.sixt@viscovery.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).