From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:59
Jeff King [off-list ref] writes:
No, I think it's right as-is. We forget about the blocks during the
recovery section of the code. IOW, we just keep reading forward until we
find all of the context lines, or we run out of trimmed content. In the
first case, we are fine (we restored the right number of context lines).
In the latter case, we are also fine, because we end up trimming nothing
(IOW, there _weren't_ enough context lines in the first place).
Kind'a embarrassing that both of us cannot get this right without so
many rounds, isn't it?
-- >8 --
Subject: [PATCH] Re-re-re-fix common tail optimization
We need to be extra careful recovering the removed common section, so
that we do not break context nor the changed incomplete line (i.e. the
last line that does not end with LF).
Signed-off-by: Junio C Hamano <redacted>
---
t/t4024-diff-optimize-common.sh | 69 +++++++++++++++++++++++++++++++++++++++
xdiff-interface.c | 2 +-
2 files changed, 70 insertions(+), 1 deletions(-)
Aren't we using "git diff" for the second diff there nowadays?
- while (recovered < trimmed && ctx)
+ while (recovered < trimmed && 0 <= ctx)
if (ap[recovered++] == '\n')
ctx--;
a->size -= (trimmed - recovered);
Oops (I think maybe I misunderstood what you were asking in the last
email). This fix is correct, though the code is now kind of subtle. I
think it would be more obvious as:
/* finish off any changed line we are in */
while (recovered < trimmed && ap[recovered++] != '\n')
/* nothing */;
/* recover context lines */
while (recovered < trimmed && ctx)
if (ap[recovered++] == '\n')
ctx--;
Your loop does both actions in the same loop, which is correct, but took
me 10 minutes of thinking and staring to realize what was going on.
-Peff
From: Charles Bailey <hidden> Date: 2016-06-15 22:44:00
On Sun, Dec 16, 2007 at 01:49:17PM -0800, Junio C Hamano wrote:
Kind'a embarrassing that both of us cannot get this right without so
many rounds, isn't it?
-- >8 --
Subject: [PATCH] Re-re-re-fix common tail optimization
We need to be extra careful recovering the removed common section, so
that we do not break context nor the changed incomplete line (i.e. the
last line that does not end with LF).
Signed-off-by: Junio C Hamano <redacted>
Just to add to the woe on this one, this test breaks on MacOS X due to
the pattern length limitations of the default sed on that platform.
Interested in a patch?
Charles.
From: Jeff King <hidden> Date: 2016-06-15 22:44:00
On Wed, Dec 19, 2007 at 02:18:45PM +0000, Charles Bailey wrote:
Just to add to the woe on this one, this test breaks on MacOS X due to
the pattern length limitations of the default sed on that platform.
Interested in a patch?
Somebody beat you to it. :) Can you confirm that the fix in
[off-list ref]
works for you?
-Peff
From: Charles Bailey <hidden> Date: 2016-06-15 22:44:00
On Wed, Dec 19, 2007 at 09:27:15AM -0500, Jeff King wrote:
On Wed, Dec 19, 2007 at 02:18:45PM +0000, Charles Bailey wrote:
quoted
Just to add to the woe on this one, this test breaks on MacOS X due to
the pattern length limitations of the default sed on that platform.
Interested in a patch?
Somebody beat you to it. :) Can you confirm that the fix in
[off-list ref]
works for you?
-Peff
Ooh, the excitement, I've never had the opportunity to "git am"
before.
Yes, I can confirm. It works for me.
For reference I had the following, which is fewer lines but not
inherently better in any other way.
Charles.
From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:00
Charles Bailey [off-list ref] writes:
On Wed, Dec 19, 2007 at 09:27:15AM -0500, Jeff King wrote:
...
quoted
Somebody beat you to it. :) Can you confirm that the fix in
[off-list ref]
works for you?
Ooh, the excitement, I've never had the opportunity to "git am"
before.
Well, if Wincent had sent the patch as plain text without MIME
quoted-printable, you did not have to even have the excitement of
running "git am", but a simple "git apply" would have sufficed.
...
How about the following? This swaps in perl in place of sed, which we c=
an
hopefully rely upon to work across platforms.
Cheers,
Wincent
-------- 8< --------
=46ix tests for broken sed on Leopard
The newly-added common-tail-optimization test fails on Leopard because
the broken sed implementation bails with a spurious "unterminated
substitute pattern" error because of the length of one of the
arguments.
Just for future reference, I do not mind avoiding "top-post" style patch
using "-- >8 --" cut markers, but do not have three or more dashes in
the cut marker. "mailinfo" will split the message at that line and the
portion intended as the proposed commit log message will be taken as
part of garbage in front of the patch. Using "-- >8 --" (two dashes,
space, scissors, ...) keeps both the front matter and the log text
together so that "am -i" or "commit --amend" can work on both parts.
By the way, how does this rewrite look?
-- >8 --
t4024: fix test script to use simpler sed pattern
The earlier test stripped away expected number of 'z' but the output
would have been very hard to read once somebody broke the common tail
optimization. Instead, count the number of 'z' and show it, to help
diagnosing the problem better in the future.
Signed-off-by: Junio C Hamano <redacted>
---
t/t4024-diff-optimize-common.sh | 158 ++++++++++++++++++++++++++++++---------
1 files changed, 123 insertions(+), 35 deletions(-)
El 20/12/2007, a las 1:21, Junio C Hamano escribió:
Charles Bailey [off-list ref] writes:
quoted
On Wed, Dec 19, 2007 at 09:27:15AM -0500, Jeff King wrote:
...
quoted
Somebody beat you to it. :) Can you confirm that the fix in
[off-list ref]
works for you?
Ooh, the excitement, I've never had the opportunity to "git am"
before.
Well, if Wincent had sent the patch as plain text without MIME
quoted-printable, you did not have to even have the excitement of
running "git am", but a simple "git apply" would have sufficed.
Well, I sent it using "git send-email", so I guess it didn't have MIME
quoted-printable.
Cheers,
Wincent
From: Charles Bailey <hidden> Date: 2016-06-15 22:44:00
On Wed, Dec 19, 2007 at 04:21:30PM -0800, Junio C Hamano wrote:
By the way, how does this rewrite look?
It looks good and the test works on my fedora and Mac OS X boxes.
(Just for reference I'm on 10.4.3, not 'Leopard'.)
I've snipped everything except zc that I wanted to comment on.
The only two really minor nits I have is that zc does bizarre things
without warning for more than 9999 "z" ( e.g. 17000 = 9000 + 8000 =
98000 (!) ) and that, from a function responsibility point of view,
the /^index/d looks rather out of place.
Perhaps a comment saying tha zc is designed for <= 9999 z's? Given
this, a lot of the /g are redundant.
But hey, it's a test script and it works and I don't have any better
suggestions. :)
Charles.