git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Björn Gustavsson" <bgustavsson@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC/PATCH 1/3] apply: Allow blank context lines to match beyond  EOF
Date: Thu, 18 Feb 2010 09:45:25 +0100	[thread overview]
Message-ID: <6672d0161002180045q7a42ae49la7831dc0431d474a@mail.gmail.com> (raw)
In-Reply-To: <7vbpfo5le0.fsf@alter.siamese.dyndns.org>

2010/2/17 Junio C Hamano <gitster@pobox.com>:

>> @@ -2002,11 +2071,17 @@ static int find_pos(struct image *img,
>>       unsigned long backwards, forwards, try;
>>       int backwards_lno, forwards_lno, try_lno;
>>
>> -     if (preimage->nr > img->nr)
>> -             return -1;
>> +     /*
>> +      * There used to be a quick reject here in case preimage
>> +      * had more lines than img. We must let match_fragment()
>> +      * handle that case because a hunk is now allowed to
>> +      * extend beyond the end of img when --whitespace=fix
>> +      * has been given (and core.whitespace.blanks-at-eof is
>> +      * enabled).
>> +      */
>
> Is it worth to keep the quick-reject if we are not running under
> blank-at-eof mode?

Good point.

As far as I can understand, the quick reject could only make
a difference if there is a huge preimage applied to a big file
and it will only make "git apply" reject the patch faster.

So I created a text file containing one million lines. I deleted
about 60% of the lines and generated a diff.

Applying that diff on the file where the lines had already
been deleted (which would be the same as trying to
apply the patch twice on the original file), "git apply"
without my branch (standard 1.7.0) needed 0.076s
to reject the patch. With my branch (i.e. without the quick
reject), "git apply" rejected the patch in 0.087s.

So unless there is some other real-world use case I haven't
thought of, it does not seem worthwhile to keep
the quick rejection test for performance reasons.

I think I'll factor out the removal of the quick reject
into a separate commit in my next revision of the patch
series, including information from this email in the
commit message.

Another thing is whether the rejection test is actually
needed for correctness reasons. As far I understand
it, is is not not. There is one test that should be changed,
though, to make it clearer why it works. I intend to include
one of the following changes in my next revision of the patch
series.

Either this one:

diff --git a/builtin-apply.c b/builtin-apply.c
index 75c04f0..d58c1ea 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2090,7 +2090,11 @@ static int find_pos(struct image *img,
        else if (match_end)
                line = img->nr - preimage->nr;

-       if (line > img->nr)
+       /*
+        * Because the comparison is unsigned, the following test
+        * will also take care of a negative line number.
+        */
+       if ((size_t) line > img->nr)
                line = img->nr;

        try = 0;

Or this one:

diff --git a/builtin-apply.c b/builtin-apply.c
index 75c04f0..8ca0e32 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2090,7 +2090,9 @@ static int find_pos(struct image *img,
        else if (match_end)
                line = img->nr - preimage->nr;

-       if (line > img->nr)
+       if (line < 0)
+               line = 0;
+       else if (line > img->nr)
                line = img->nr;

        try = 0;

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB

      reply	other threads:[~2010-02-18  8:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-17  7:03 [RFC/PATCH 1/3] apply: Allow blank context lines to match beyond EOF Björn Gustavsson
2010-02-17  8:14 ` Junio C Hamano
2010-02-18  8:45   ` Björn Gustavsson [this message]

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=6672d0161002180045q7a42ae49la7831dc0431d474a@mail.gmail.com \
    --to=bgustavsson@gmail.com \
    --cc=git@vger.kernel.org \
    --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 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 NNTP newsgroup(s).