git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	Brandon Williams <bmwill@google.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 1/2] ls-files: adding support for submodules
Date: Thu, 22 Sep 2016 09:04:35 -0700	[thread overview]
Message-ID: <CAGZ79kYQVhVN1mzJCWCH8bLEFTmgL8yqrN=KUiAY5PT1t7-D6A@mail.gmail.com> (raw)
In-Reply-To: <20160922041854.7754ujcynhk7mdnh@sigill.intra.peff.net>

On Wed, Sep 21, 2016 at 9:18 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Sep 21, 2016 at 04:13:22PM -0700, Junio C Hamano wrote:
>
>> Brandon Williams <bmwill@google.com> writes:
>>
>> > yes you mentioned this and I meant to change that before sending it out.
>> > Looks like it slipped through have slipped through.
>>
>> I already fixed it up locally when I sent the reply, but thanks for
>> resending (which assures me that your local copy is up-to-date and I
>> do not have to worry about having to repeat me in the future, if
>> this ever needs further rerolling ;-).
>
> While we are on the subject, the commit message also uses some past
> tense:
>
>   Allow ls-files to recognize submodules in order to retrieve a list of
>   files from a repository's submodules.  This is done by forking off a
>   process to recursively call ls-files on all submodules. Also added a
>   submodule-prefix command in order to prepend paths to child processes.
>
> The final sentence should be "Also add...".
>
> Since this final bit of logic was sufficiently non-obvious that it only
> came about in v2, maybe it is worth describing a little more fully:
>
>   Also add a submodule-prefix option, which instructs the child
>   processes to prepend the prefix to each path they output. This makes
>   the output paths match what is on the filesystem (i.e., as if the
>   submodule boundaries were not there at all).
>
> Should this option just be "--prefix", or maybe "--output-prefix"?

I think --prefix can easily be confused with the internal prefix that we hand
down to each command. --output-prefix works for the ls-files case, but as
soon as we do more than just printing out file names, we'd use that prefix for
more than just output, e.g. in grep it becomes part of the pathspec IIUC.
I agree however that we probably don't want to keep it submodule specific.

> Submodules are the obvious use case here, but I could see somebody
> adapting this for other uses (alternatively, if we _do_ want to keep it
> just as an implementation detail for submodules, we should probably
> discourage people in the documentation from using it themselves).
>
> -Peff

  reply	other threads:[~2016-09-22 16:04 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 [this message]
2016-09-22 18:13           ` Junio C Hamano
2016-09-23  3:41             ` Jeff King
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='CAGZ79kYQVhVN1mzJCWCH8bLEFTmgL8yqrN=KUiAY5PT1t7-D6A@mail.gmail.com' \
    --to=sbeller@google.com \
    --cc=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).