GIT_ONE_FILESYSTEM inclusion?

Hi all,

Just wondering if anyone has any further comments or suggestions for the
GIT_ONE_FILESYSTEM patches I posted. See here for context:

    http://thread.gmane.org/gmane.comp.version-control.git/142436

If it looks good I'd love to have it considered for inclusion.

Thanks!
-lars

--
lars r. damerow :: button pusher :: pixar animation studios

On Wed, Mar 24, 2010 at 00:20, Lars Damerow [off-list ref] wrote:

Just wondering if anyone has any further comments or suggestions for the
GIT_ONE_FILESYSTEM patches I posted. See here for context:

   http://thread.gmane.org/gmane.comp.version-control.git/142436

If it looks good I'd love to have it considered for inclusion.

Have considered making it an option to git wrapper as suggested
(-x/--one-filesystem)?
And while at it, how about making it a config option? (i.e. core.oneFilesystem?)

Am 3/24/2010 10:29, schrieb Alex Riesen:

And while at it, how about making it a config option? (i.e. core.oneFilesystem?)

It's difficult to have this as a config option when you are looking for a
repository... ;)

-- Hannes

On Wed, Mar 24, 2010 at 10:35, Johannes Sixt [off-list ref] wrote:

Am 3/24/2010 10:29, schrieb Alex Riesen:

quoted

And while at it, how about making it a config option? (i.e. core.oneFilesystem?)

It's difficult to have this as a config option when you are looking for a
repository... ;)

Isn't it a little pointless to look for repository when you can't
access its config?

From Alex Riesen [off-list ref], Wed, Mar 24, 2010 at 12:37:39PM +0100:

Isn't it a little pointless to look for repository when you can't
access its config?

If you're doing the trendy thing of putting repository information in
your shell prompt, then your prompt is looking for a repository every
time you change a directory.

As for making this a command-line option: that's certainly doable, but
it makes it harder to enforce the option's use across an organization.
It's far easier for me to set an environment variable centrally on a
thousand workstations than to convince a potentially large number of
users to set a new shell alias for git.

thanks,
-lars

--
lars r. damerow :: button pusher :: pixar animation studios

On Wed, Mar 24, 2010 at 14:40, Lars Damerow [off-list ref] wrote:

From Alex Riesen [off-list ref], Wed, Mar 24, 2010 at 12:37:39PM +0100:

quoted

Isn't it a little pointless to look for repository when you can't
access its config?

If you're doing the trendy thing of putting repository information in
your shell prompt, then your prompt is looking for a repository every
time you change a directory.

Right. OTOH, if you know that your .git is accessible (on the right
filesystem), but want to avoid scans in the directories below the top-
level working directory (submodules?), you may want to have it
configurable per-repository. The environment variable will affect
scan in all your repositories you visit in this session, which maybe
what you want, and maybe not.
And yes, the config option is also in addition to, not instead of
the environment variable.

As for making this a command-line option: that's certainly doable, but
it makes it harder to enforce the option's use across an organization.
It's far easier for me to set an environment variable centrally on a
thousand workstations than to convince a potentially large number of
users to set a new shell alias for git.

Oh, I wasn't clear. I didn't mean "instead of". A command-line option
_in_addition_ to the environment variable. For one-off uses.