Alex Riesen <raa.lkml@xxxxxxxxx> wrote: > 2008/9/24 Dmitry Potapov <dpotapov@xxxxxxxxx>: > > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
