git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Brandon Williams <bmwill@google.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:17:49 -0700	[thread overview]
Message-ID: <xmqqponqseya.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160926170429.GA3624@google.com> (Brandon Williams's message of "Mon, 26 Sep 2016 10:04:29 -0700")

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

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

  reply	other threads:[~2016-09-26 18:17 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 [this message]
2016-09-26 18:38           ` Brandon Williams
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=xmqqponqseya.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --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).