[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH] add GIT_FAST_STAT mode for Cygwin
From:       "Shawn O. Pearce" <spearce () spearce ! org>
Date:       2008-09-24 15:02:31
Message-ID: 20080924150231.GO3669 () spearce ! org
[Download RAW message or body]

Alex Riesen <raa.lkml@gmail.com> wrote:
> 2008/9/24 Dmitry Potapov <dpotapov@gmail.com>:
> 
> > Frankly, I don't have strong preference here neither for making this
> > fast version always work nor leave it conditional (perhaps, with the
> > default setting use-fast-version). So, whatever the majority decides
> > is fine with me.
> 
> I'm voting for compile-time configuration then.

To be consistent with everything else, compile-time sounds like
what we should do, its how just about every other part of Git
is configured.

However Dmitry pointed out that he has cases where this faster
function doesn't work correctly, and it was path specific.  Some
areas of the filesystem work, others don't, on the same system.
A current example of a feature more like this is core.filemode.

A compile-time option makes the feature useful only to those users
who don't ever have a repository which has a mount contained within
the working directory.  My understanding of Dmitry's explanation
is he has such cases, which is why I was voting for a runtime
configuration.

A compile-time option means that Git will work fine for years, until
you put a mount in a working directory and *wham* it suddenly stops
working like it should, because of that compile-time optimization
you made long ago and forgot about.
 
> >> Besides it will remove your setup code, which looks bigger and provoked
> >> more discussion than the real subject itself.
> >
> > I believe Shawn wanted it to be configurable on per-repository basis.
> 
> which, I believe, is pointless.

See above.  I suggested configurable per-repository because
Dmitry seemed to be saying this feature only works in some of his
repositories and not others.  Controlling it by an environment
variable isn't very easy to use as you move between repositories
on the same system.

Maybe I should have leaned more towards compile-time earlier in
the discussion, but Dmitry lead off the patch though with a remark
about users just running the Cygwin package, without building
their own Git.  We can't expect the Cygwin maintainers to enable
a feature in a software package that makes it work on 90% of the
Cygwin installs out there; that's just asking for trouble.

But we can compile in a user-configurable switch, where the user can
shoot their own foot off in the name of speed, especially if they
can easily disable it on the oddball repositories where it fails.

Of course it might be even better if the code could auto-sense
when its busted and just switch itself off.  E.g. if four or
more consecutive "fast" stat calls fail but the original Cygwin
call succeeds then just always use Cygwin calls for the rest of
the process.

-- 
Shawn.
--
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
[prev in list] [next in list] [prev in thread] [next in thread]