Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 21, 2008, 21:22 UTC
Message-ID: <alpine.LFD.1.00.0801211242330.2957@woody.linux-foundation.org>
In-Reply-To: <7vabmyykvg.fsf@gitster.siamese.dyndns.org>

On Mon, 21 Jan 2008, Junio C Hamano wrote:

Show 6 quoted lines

> >
> > I'd forgotten about that really ugly special case. It's no longer ugly, 
> > but missing that part of the ce_mode handling cleanup certainly explains 
> > the test-suite failing.
> 
> Very good catch.

The stupid thing is that I literally _grepped_ for the code testing "ce_mode".

I had missed that one because I had looked for things like

	if ([!].*ce_mode)

but that switch statement meant that the comparison to zero was non-local and my grep didn't see it. And while the test-suite did have a test for this, it was hidden by the racy index logic.. Unlucky.

Anyway, I've created a rebased tree with the commits fixed (and some whitespace fixes too), so that it should hopefully all be bisect-clean etc.

[ To clarify: it's both rebased to the current git 'master' (which is 
  currently -rc4) _and_ it has the commits fixed up. So I also squashed 
  the "-m" flag fix into the commit that made diff-index use unpack_trees, 
  etc, so that none of the commits should be introducing bugs that get 
  fixed later.

  I also cleaned up some of the commit messages, particularly the one 
  about using unpack_trees() (which was talking about "take 2" of lstat 
  reduction - true, but not very descriptive of what it actually did) ]

It's in the same place: branch 'new-lstat' at

	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git new-lstat

and I'll continue to maintain it if only because it's what I use myself (until I just switch to 'next' or something).

		Linus