Re: [PATCH 1/2] ls-files: adding support for submodules

From: Stefan Beller <sbeller@google.com>
Date: Sep 23, 2016, 16:34 UTC
Message-ID: <CAGZ79kYF6nYL42VQ_mbVzD+2QFLPELe9-8DOQjbSwArM20SCKA@mail.gmail.com>
In-Reply-To: <CAKoko1p+M3X_y+DH+65fUDRZjkiZrKE3Z-jjq=RSjqoi7He8pw@mail.gmail.com>

On Fri, Sep 23, 2016 at 9:16 AM, Brandon Williams <bmwill@google.com> wrote:

Show 11 quoted lines

>> Yeah, a positive "I support this" flag would at least let us correctly
>> flag errors, which is the best we can do. That won't work for
>> non-builtins, but perhaps it is good enough in practice.
>>
>> -Peff
>
>
> So it sounds like we agree that this prefix option should be pushed to
> the top level.
> The question is have we come to a consensus on what we should be
> calling the option?

The option itself is very similar to -C, which changes the directory to the given argument before executing the git command. e.g. in git:

    git -C builtin ls-files
    add.c
    ...

So for the submodule case we'd want that plus keeping around that prefix, which makes me wonder if we could just store the argument of -C into a global and use that when --keep-prefix is given, so you'd do a

    git -C path/to/sub --keep-prefix ls-files
    path/to/sub/file1
    ...

maybe --[keep|use]-[path|prefix] ?

You could of course go with a fully independent option, but how would that work together with -C ? (first change the dir and then change again while remembering the prefix? or the other way round?)

> Leave it as submodule-prefix or do we need to come up with a different name?
>
> -Brandon