On Tue, Aug 07, 2007 at 08:32:55AM +0200, David Kastrup wrote:
quoted text
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html