GIT_ONE_FILESYSTEM inclusion?

GIT_ONE_FILESYSTEM inclusion?

[Lars Damerow]

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

Re: GIT_ONE_FILESYSTEM inclusion?

[Alex Riesen]

On Wed, Mar 24, 2010 at 00:20, Lars Damerow <lars@pixar.com> 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?)

Re: GIT_ONE_FILESYSTEM inclusion?

[Johannes Sixt]

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

Re: GIT_ONE_FILESYSTEM inclusion?

[Alex Riesen]

On Wed, Mar 24, 2010 at 10:35, Johannes Sixt <j.sixt@viscovery.net> wrote:
> 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... ;)
>

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

Re: GIT_ONE_FILESYSTEM inclusion?

[Lars Damerow]

>From Alex Riesen <raa.lkml@gmail.com>, 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

Re: GIT_ONE_FILESYSTEM inclusion?

[Alex Riesen]

On Wed, Mar 24, 2010 at 14:40, Lars Damerow <lars@pixar.com> wrote:
> From Alex Riesen <raa.lkml@gmail.com>, 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.

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.

Re: GIT_ONE_FILESYSTEM inclusion?

[Junio C Hamano]

Alex Riesen <raa.lkml@gmail.com> writes:

> 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.

I may have been the one who mentioned "-x to git potty" as a possibility,
but I agree with Lars---I think it would be too cumbersome to use in
practice.

When would you invoke this feature as "one-off"?

Re: GIT_ONE_FILESYSTEM inclusion?

[Alex Riesen]

On Wed, Mar 24, 2010 at 17:33, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> 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.
>
> I may have been the one who mentioned "-x to git potty" as a possibility,
> but I agree with Lars---I think it would be too cumbersome to use in
> practice.
>
> When would you invoke this feature as "one-off"?
>

Maybe when I want to make sure git status does not go all over an
NFS mounted submodule.

But frankly, I think it will be the most obscure feature of Git ever,
with a command-line option or without. I just wanted to suggest
(and actually, just should have, stupid me) to keep it in line with
other similar configurations, which are present in all three forms
(work tree comes to mind... Come to think of it, only the work tree).

Re: GIT_ONE_FILESYSTEM inclusion?

[Junio C Hamano]

Alex Riesen <raa.lkml@gmail.com> writes:

>> When would you invoke this feature as "one-off"?
>
> Maybe when I want to make sure git status does not go all over an
> NFS mounted submodule.

But then what would you do after finding it out that it might?  You stop
working on that project?  Doesn't --ignore-submodules do the same thing?

Re: GIT_ONE_FILESYSTEM inclusion?

[Alex Riesen]

On Wed, Mar 24, 2010 at 21:04, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>>> When would you invoke this feature as "one-off"?
>>
>> Maybe when I want to make sure git status does not go all over an
>> NFS mounted submodule.
>
> But then what would you do after finding it out that it might?  You stop

Postpone whatever you were about to do, maybe.

> working on that project?  Doesn't --ignore-submodules do the same thing?

It does. I said it is obscure.

Re: GIT_ONE_FILESYSTEM inclusion?

[Lars Damerow]

>From Alex Riesen <raa.lkml@gmail.com>, Wed, Mar 24, 2010 at 08:07:03PM +0100:
> But frankly, I think it will be the most obscure feature of Git ever,

Wow. Would I win a prize or something? :)

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

Re: GIT_ONE_FILESYSTEM inclusion?

[Matthieu Moy]

Alex Riesen <raa.lkml@gmail.com> writes:

> On Wed, Mar 24, 2010 at 10:35, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> 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... ;)
>>
>
> Isn't it a little pointless to look for repository when you can't
> access its config?

I guess Johannes's point is that the config option can be in
$GIT_DIR/config, which you can't access when looking for $GIT_DIR.
OTOH, looking at ~/.gitconfig to find a core.oneFilesystem makes sense
(but is probably painfull to implement since the current code to parse
config file will look for $GIT_DIR first).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GIT_ONE_FILESYSTEM inclusion?

[David Aguilar]

On Wed, Mar 24, 2010 at 02:43:26PM +0100, Matthieu Moy wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
> 
> > On Wed, Mar 24, 2010 at 10:35, Johannes Sixt <j.sixt@viscovery.net> wrote:
> >> 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... ;)
> >>
> >
> > Isn't it a little pointless to look for repository when you can't
> > access its config?
> 
> I guess Johannes's point is that the config option can be in
> $GIT_DIR/config, which you can't access when looking for $GIT_DIR.
> OTOH, looking at ~/.gitconfig to find a core.oneFilesystem makes sense
> (but is probably painfull to implement since the current code to parse
> config file will look for $GIT_DIR first).
> 
> -- 
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/

Right.

As this thread showed, we can't have a config option for this
feature.  Were there any other objections to the patch?
It looks good to me.

Peff also agreed that it was an overall improvement.
http://thread.gmane.org/gmane.comp.version-control.git/142262

Thread with the latest (v3) version of the patch:
http://thread.gmane.org/gmane.comp.version-control.git/142436

We could use this feature at Disney Animation as well.
We maintain a list of $GIT_CEILING_DIRECTORIES and could do
without having to maintain it if we had this feature.


Plus, Lars is one of the git users that doesn't even flinch when
the Perforce servers at Pixar get a hiccup, so we should try and
help our fellow "renegade" git users ;-)

-- 
		David

Re: GIT_ONE_FILESYSTEM inclusion?

[Jeff King]

On Sat, Mar 27, 2010 at 03:27:32PM -0700, David Aguilar wrote:

> Peff also agreed that it was an overall improvement.
> http://thread.gmane.org/gmane.comp.version-control.git/142262
> 
> Thread with the latest (v3) version of the patch:
> http://thread.gmane.org/gmane.comp.version-control.git/142436

Yep.  I had been meaning to review v3, and I just did. With the
exception of a few minor nits (which I posted in that thread), I think
it looks good.

-Peff