git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Brandon Williams <bmwill@google.com>, git@vger.kernel.org
Subject: Re: [PATCH 1/2] ls-files: adding support for submodules
Date: Thu, 22 Sep 2016 23:41:13 -0400	[thread overview]
Message-ID: <20160923034113.4rnps3nogvzxkfjx@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqq7fa36bwm.fsf@gitster.mtv.corp.google.com>

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

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

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

  reply	other threads:[~2016-09-23  3:41 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-21 22:04 [PATCH 1/2] ls-files: adding support for submodules Brandon Williams
2016-09-21 22:04 ` [PATCH 2/2] ls-files: add pathspec matching " Brandon Williams
2016-09-21 22:53   ` Junio C Hamano
2016-09-21 23:23     ` Brandon Williams
2016-09-21 23:28       ` [PATCH 2/2 v2] " Brandon Williams
2016-09-23 18:48         ` Junio C Hamano
2016-09-23 19:20         ` Junio C Hamano
2016-09-23 20:49           ` Brandon Williams
2016-09-21 22:08 ` [PATCH 1/2] ls-files: adding support " Brandon Williams
2016-09-21 22:28   ` Junio C Hamano
2016-09-21 22:38     ` Brandon Williams
2016-09-21 22:42       ` [PATCH 1/2] ls-files: optionally recurse into submodules Brandon Williams
2016-09-22  6:20         ` Jeff King
2016-09-23 23:31           ` Brandon Williams
2016-09-21 23:13       ` [PATCH 1/2] ls-files: adding support for submodules Junio C Hamano
2016-09-22  4:18         ` Jeff King
2016-09-22 16:04           ` Stefan Beller
2016-09-22 18:13           ` Junio C Hamano
2016-09-23  3:41             ` Jeff King [this message]
2016-09-23  5:47               ` Stefan Beller
2016-09-23  6:06                 ` Jeff King
2016-09-23 16:16                   ` Brandon Williams
2016-09-23 16:34                     ` Stefan Beller
2016-09-25 11:03                       ` Nazri Ramliy
2016-09-27 21:38             ` Junio C Hamano
2016-09-27 21:48               ` Brandon Williams
2016-09-27 22:01                 ` Junio C Hamano
2016-09-27 22:09                   ` Brandon Williams
2016-09-27 22:23                     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160923034113.4rnps3nogvzxkfjx@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).