Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged

From: J. Bruce Fields <bfields@fieldses.org>
Date: Aug 7, 2007, 13:34 UTC
Message-ID: <20070807133458.GA19834@fieldses.org>
In-Reply-To: <86k5s7am7c.fsf@lola.quinscape.zz>

On Tue, Aug 07, 2007 at 08:32:55AM +0200, David Kastrup wrote:

Show 21 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> >
> >> Unfortunately, the patch solves the "large and irrelevant output"
> >> of git-diff, but not the performance problem (see the rest of the
> >> thread, I failed to convince Junio that updating the index was a
> >> performance improvement while keeping the same user semantics).
> >
> > That's what update-index --refresh (or status if you insist) are
> > for, and the coalmine canary you are so dead set to kill are helping
> > you realize the need for running.
> 
> That does not convince me.  Cache staleness should be a problem of
> git, not of the user.  In particular if the user is just using
> porcelain.  If letting the cache get stale impacts performance, then
> git should clean up its act on its own without barfing when using
> unrelated commands.  If it notices this during diff (presumably by
> overstepping some staleness ratio), then it can set a "regenerate on
> next opportunity" flag on the index, and then the next command wanting
> to process the index from the start can rewrite a refreshed version.

The last time I had a serious problem with "cache staleness", it was with Beagle, which modifies the files it indexes (by writing some extended attributes). I figured out what was happening when I noticed that the list of touched files was growing each time I did a diff (implying the something was working on them right then), so I ran top, noticed beagled, eventually thought to query the extended attributes, and finally turned off beagled's indexing to solve the problem.

So, in this case:

	- If git had fixed up the problem silently, I probably would
	  have just assumed git was slow and not found the problem.

	- Seeing the actual list of files for which the index was dirty
	  helped me identify the problem.  I probably would have
	  eventually figured it out even if all I'd had was a single
	  "index is stale" message, but I suspect it would have taken
	  longer.

Draw whatever moral you'd like....

--b.