From: Linus Torvalds <torvalds@linux-foundation.org>
To: Kyle McMartin <kyle@mcmartin.ca>,
Junio C Hamano <gitster@pobox.com>,
Git Mailing List <git@vger.kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.6.24-rc6
Date: Thu, 20 Dec 2007 20:22:46 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.0.9999.0712202009290.21557@woody.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.0.9999.0712201937470.21557@woody.linux-foundation.org>
On Thu, 20 Dec 2007, Linus Torvalds wrote:
>
> The tar-ball and the git archive itself is fine, but yes, the diff from
> 2.6.23 to 2.6.24-rc6 is bad. It's the "trim_common_tail()" optimization
> that has caused way too much pain.
Very interesting breakage. The patch was actually "correct" in a (rather
limited) technical sense, but the context at the end was missing because
while the trim_common_tail() code made sure to keep enough common context
to allow a valid diff to be generated, the diff machinery itself could
decide that it could generate the diff differently than the "obvious"
solution.
It only happened for a few files that had lots of repeated lines - so that
the diff could literally be done multiple different ways - and in fact,
the file that caused the problems really had a bogus commit that
duplicated *way* too much data, and caused lots of #define's to exist
twice.
But the sad fact appears that the git optimization (which is very
important for "git blame", which needs no context), is only really valid
for that one case where we really don't need any context.
I uploaded a fixed patch. And here's the git patch to avoid this
optimization when there is context.
Linus
---
xdiff-interface.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/xdiff-interface.c b/xdiff-interface.c
index 9ee877c..0b7e057 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -110,22 +110,22 @@ int xdiff_outf(void *priv_, mmbuffer_t *mb, int nbuf)
static void trim_common_tail(mmfile_t *a, mmfile_t *b, long ctx)
{
const int blk = 1024;
- long trimmed = 0, recovered = 0;
+ long trimmed = 0;
char *ap = a->ptr + a->size;
char *bp = b->ptr + b->size;
long smaller = (a->size < b->size) ? a->size : b->size;
+ if (ctx)
+ return;
+
while (blk + trimmed <= smaller && !memcmp(ap - blk, bp - blk, blk)) {
trimmed += blk;
ap -= blk;
bp -= blk;
}
- while (recovered < trimmed && 0 <= ctx)
- if (ap[recovered++] == '\n')
- ctx--;
- a->size -= (trimmed - recovered);
- b->size -= (trimmed - recovered);
+ a->size -= trimmed;
+ b->size -= trimmed;
}
int xdi_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp, xdemitconf_t const *xecfg, xdemitcb_t *xecb)
next prev parent reply other threads:[~2007-12-21 4:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-21 1:41 Linus Torvalds
2007-12-21 2:40 ` Zhang, Yanmin
2007-12-21 2:48 ` Kyle McMartin
2007-12-21 3:01 ` Kyle McMartin
2007-12-21 3:49 ` Linus Torvalds
2007-12-21 3:50 ` Kyle McMartin
2007-12-21 4:22 ` Linus Torvalds [this message]
2007-12-21 4:40 ` Linus Torvalds
2007-12-21 4:50 ` Kyle McMartin
2007-12-21 4:58 ` Linus Torvalds
2007-12-21 16:56 ` Junio C Hamano
2007-12-21 3:23 ` [PATCH] mbx: Fix up duplicate defines in reg_bits.h Kyle McMartin
2007-12-23 0:05 ` Linux 2.6.24-rc6 S.Çağlar Onur
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=alpine.LFD.0.9999.0712202009290.21557@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kyle@mcmartin.ca \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®