git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Brandon Williams <bmwill@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: [PATCH 0/3] recursive support for ls-files
Date: Mon, 26 Sep 2016 11:38:11 -0700	[thread overview]
Message-ID: <20160926183811.GA5123@google.com> (raw)
In-Reply-To: <xmqqponqseya.fsf@gitster.mtv.corp.google.com>

On 09/26, Junio C Hamano wrote:
> Brandon Williams <bmwill@google.com> writes:
> 
> > In a previous email you mentioned that this feature should be completely
> > hidden from users, which is why I removed the command line option for
> > this latest series.
> 
> I may have said something like that; I do not recall, though, so a
> more accurate description might be "I may have said something that
> can be (mis)interpreted like so".  Sorry for the confusion.
> 
> In any case, an environment is not "completely hidden from users",
> so it is not fundamentallly different from a command line option
> anyway ;-)

No worries, I'm still trying to get a hang of all this :)
True, that wouldn't be completely hidden either.

> > If that isn't what you intended that I can
> > definitely add the option to git.c.  And you would rather we perform the
> > checking in git.c to see if a subcommand supports the prefix versus
> > silently ignoring it if it hasn't?  I'm assuming this checking would
> > also be done in git.c?
> 
> I actually do not care strongly _where_ the check happens.  It was
> just that in the subcommand dispatcher would be the single place
> that is easiest-to-implement to perform that check, that made me
> suggest that.  We already have various bits like NEEDS_WORK_TREE,
> RUN_SETUP, etc. so REJECT_EXTERNAL_PREFIX (or whatever its name be;
> I do not offhand recall current proposal) bit would fit there
> naturally, I would think.  Of course, non-built-in commands need to
> protect themselves separately, if they want to.

That makes sense.  I have an idea of where the check could be made. And
with those flags it may make sense to have the flag be an indicator that
the builtin is ready for submodule type commands ie SUPPORTS_SUBMODULES
or something along those lines.  That way we only need to add the flag
to each command as we go (instead of all commands which don't support
it) and just make sure that the flag is set if the submodule prefix
option is being used.  How does that sound?

-- 
Brandon Williams

  reply	other threads:[~2016-09-26 18:38 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-24  0:13 [PATCH 0/3] recursive support for ls-files Brandon Williams
2016-09-24  0:13 ` [PATCH 1/3 v3] submodules: make submodule-prefix option an envvar Brandon Williams
2016-09-25 23:34   ` Junio C Hamano
2016-09-24  0:13 ` [PATCH 2/3 v3] ls-files: optionally recurse into submodules Brandon Williams
2016-09-24  0:13 ` [PATCH 3/3 v3] ls-files: add pathspec matching for submodules Brandon Williams
2016-09-25  7:17 ` [PATCH 0/3] recursive support for ls-files Jeff King
2016-09-25 16:32   ` Brandon Williams
2016-09-25 18:38     ` Junio C Hamano
2016-09-26 17:04       ` Brandon Williams
2016-09-26 18:17         ` Junio C Hamano
2016-09-26 18:38           ` Brandon Williams [this message]
2016-09-26 18:48             ` Junio C Hamano
2016-09-26 22:46 ` [PATCH 0/4 v4] " Brandon Williams
2016-09-26 22:46   ` [PATCH 1/4 v4] submodules: make submodule-prefix option Brandon Williams
2016-09-27 18:17     ` Junio C Hamano
2016-09-27 20:29       ` Brandon Williams
2016-09-27 20:35         ` Junio C Hamano
2016-09-27 20:43           ` Brandon Williams
2016-09-26 22:46   ` [PATCH 2/4 v4] ls-files: optionally recurse into submodules Brandon Williams
2016-09-27 18:29     ` Junio C Hamano
2016-09-27 20:33       ` Brandon Williams
2016-09-26 22:46   ` [PATCH 3/4 v4] ls-files: pass through safe options for --recurse-submodules Brandon Williams
2016-09-27 18:40     ` Junio C Hamano
2016-09-27 20:11       ` Junio C Hamano
2016-09-27 20:52         ` Brandon Williams
2016-09-27 20:58           ` Junio C Hamano
2016-09-27 20:59           ` Stefan Beller
2016-09-28 17:24         ` Brandon Williams
2016-09-28 18:59           ` Junio C Hamano
2016-09-27 20:49       ` Brandon Williams
2016-09-27 18:43     ` Junio C Hamano
2016-09-27 20:44       ` Brandon Williams
2016-09-27 20:59         ` Junio C Hamano
2016-09-26 22:46   ` [PATCH 4/4 v4] ls-files: add pathspec matching for submodules Brandon Williams
2016-09-27 20:01     ` Junio C Hamano
2016-09-27 20:40       ` Brandon Williams
2016-09-28 21:50   ` [PATCH v5 0/4] recursive support for ls-files Brandon Williams
2016-09-28 21:50     ` [PATCH v5 1/4] git: make super-prefix option Brandon Williams
2016-09-28 22:01       ` Stefan Beller
2016-09-28 22:19       ` Junio C Hamano
2016-09-29 18:39       ` Jeff King
2016-09-29 18:44         ` Brandon Williams
2016-09-28 21:50     ` [PATCH v5 2/4] ls-files: optionally recurse into submodules Brandon Williams
2016-09-28 22:11       ` Stefan Beller
2016-09-28 22:22       ` Junio C Hamano
2016-09-28 21:50     ` [PATCH v5 3/4] ls-files: pass through safe options for --recurse-submodules Brandon Williams
2016-09-28 21:50     ` [PATCH v5 4/4] ls-files: add pathspec matching for submodules Brandon Williams
2016-09-29 21:48     ` [PATCH v6 0/4] recursive support for ls-files Brandon Williams
2016-09-29 21:48       ` [PATCH v6 1/4] git: make super-prefix option Brandon Williams
2016-10-04 17:31         ` Stefan Beller
2016-10-04 17:35           ` Junio C Hamano
2016-10-04 17:39           ` Jeff King
2016-09-29 21:48       ` [PATCH v6 2/4] ls-files: optionally recurse into submodules Brandon Williams
2016-09-29 21:48       ` [PATCH v6 3/4] ls-files: pass through safe options for --recurse-submodules Brandon Williams
2016-09-30  0:14         ` Junio C Hamano
2016-09-30 16:33           ` Brandon Williams
2016-09-30 17:01             ` Brandon Williams
2016-09-29 21:48       ` [PATCH v6 4/4] ls-files: add pathspec matching for submodules Brandon Williams
2016-10-04 17:56         ` Stefan Beller
2016-10-07 18:18       ` [PATCH v7 0/4] recursive support for ls-files Brandon Williams
2016-10-07 18:18         ` [PATCH v7 1/4] git: make super-prefix option Brandon Williams
2016-10-07 18:18         ` [PATCH v7 2/4] ls-files: optionally recurse into submodules Brandon Williams
2016-10-07 18:18         ` [PATCH v7 3/4] ls-files: pass through safe options for --recurse-submodules Brandon Williams
2016-10-07 18:18         ` [PATCH v7 4/4] ls-files: add pathspec matching for submodules Brandon Williams
2016-10-07 18:34         ` [PATCH v7 0/4] recursive support for ls-files Stefan Beller
2016-10-07 18:35           ` Stefan Beller
2016-10-07 18:45             ` Brandon Williams

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=20160926183811.GA5123@google.com \
    --to=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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).