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

From: Jeff King <peff@peff.net>
Date: Sep 23, 2016, 03:41 UTC
Message-ID: <20160923034113.4rnps3nogvzxkfjx@sigill.intra.peff.net>
In-Reply-To: <xmqq7fa36bwm.fsf@gitster.mtv.corp.google.com>

On Thu, Sep 22, 2016 at 11:13:13AM -0700, Junio C Hamano wrote:

Show 5 quoted lines

> In any case, I would strongly recommend against exposing this (or
> anything for that matter) "--prefix" to the end-user, especially
> because this feature is likely to be applicable to many subcommands,
> and some subcommands would want different sort of prefixing made to
> different things.

Fair enough. I was thinking that this was similar to other options like "read-tree --prefix" or "archive --prefix". But if nobody really wants it for anything non-internal, then certainly keeping it as an internal feature is an easy way to avoid being stuck with a bad public interface in the long term.

> What we internally call "prefix" and "--submodule-prefix" is closely
> related in that they both interact with pathspecs.

Yeah, I didn't think about pathspecs at all (since they are totally disabled in patch 1, and I hadn't really read through patch 2 carefully yet).

>  * As Stefan alluded to (much) earlier, it might be a better idea
>    to have these 'prefix' as the global option to "git" potty, not
>    to each subcommand that happens to support them;

That seems like it would be nice, but there's going to be an interim period where some commands do not respect the global "--prefix" at all (in the worst case, consider a third party command).

Show 12 quoted lines

>  * It is unclear how this should interact with commands that are run
>    in a subdirectory of the working tree.  E.g. what should the
>    prefix and the pathspec look like if the command in the above
>    example is started in w/git.git/Documentation subdirectory, i.e.
> 
>     $ cd ~
>     $ git -C w/git.git/Documentation ls-files \
>         --submodule-prefix=??????? -- '???????' |
>       xargs ls -1 -l
> 
>    Should we error out if we are not at the top of the working tree
>    when --submodule-prefix is given?

Without thinking too hard on it, it seems like the submodule prefix just needs to come after the normal "prefix" that we add when moving to the top-level of a tree. So:

  cd foo
  git ls-files --submodule-prefix=bar

should show "foo/bar". Or another way of thinking about it is that the submodule prefix is always relative to the current directory. Recursion into submodule would always happen at their top-level, and so would do the right thing.

But again, that's without thinking hard on it. There may be some corner cases.

-Peff