From: Junio C Hamano <gitster@pobox.com>
To: Brandon Williams <bmwill@google.com>
Cc: Heiko Voigt <hvoigt@hvoigt.net>,
git@vger.kernel.org, pclouds@gmail.com,
Jens Lehmann <jens.lehmann@web.de>,
Stefan Beller <sbeller@google.com>
Subject: Re: [RFC] extending pathspec support to submodules
Date: Thu, 15 Sep 2016 15:08:37 -0700 [thread overview]
Message-ID: <xmqqr38klst6.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAKoko1rtEydwbWoEq9MBW41qqa10Bm+x0d6zS+Bptk51RjMOMA@mail.gmail.com> (Brandon Williams's message of "Thu, 15 Sep 2016 08:26:22 -0700")
Brandon Williams <bmwill@google.com> writes:
> You're right that seems like the best course of action and it already falls
> inline with what I did with a first patch to ls-files to support submodules.
> In that patch I did exactly as you suggest and pass in the prefix to the
> submodule and make the child responsible for prepending the prefix to all of
> its output. This way we can simply pass through the whole pathspec (as apposed
> to my original idea of stripping the prefix off the pathspec prior to passing
> it to the child...which can get complicated with wild characters) to the
> childprocess and when checking if a file matches the pathspec we can check if
> the prefix + file path matches.
That's brilliant. A few observations.
* With that change to tell the command that is spawned in a
submodule directory where the submodule repository is in the
context of the top-level superproject _and_ require it to take a
pathspec as relative to the top-level superproject, you no longer
worry about having to find where to cut the pathspec given at the
top-level to adjust it for the submodule's context. That may
simplify things.
* Your program that runs in the top-level superproject still needs
to be able to say "this pathspec from the top cannot possibly
match anything in the submodule, so let's not even bother
descending into it".
* Earlier while reviewing "ls-files" recursion, I suggested (and
you took) --output-path-prefix as the option name, because it was
meant to be "when you output any path, prefix this string". But
the suggested name is suboptimal, as it is no longer an option
that is only about "output". A command that runs in a submodule
would:
- enumerate paths in the context of the submodule repository,
- prepend the "prefix" to these paths,
- filter by applying the full-tree pathspec, and
- work on the surviving paths after filtering.
When the last step, "work on", involves just "printing", the
whole path (with "prefix") is sent to the output. If it involves
some operation relative to the submodule repository (e.g. seeing
if it is in the index), the "prefix" may have to be stripped
while the operation is carried out.
So we may have to rethink what this option name should be. "You
are running in a repository that is used as a submodule in a
larger context, which has the submodule at this path" is what the
option tells the command; if any existing command already has
such an option, we should use it. If we are inventing one,
perhaps "--submodule-path" (I didn't check if there are existing
options that sound similar to it and mean completely different
things, in which case that name is not usable)?
Thanks.
next prev parent reply other threads:[~2016-09-15 22:08 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 23:57 [RFC] extending pathspec support to submodules Brandon Williams
2016-09-15 11:57 ` Heiko Voigt
2016-09-15 15:26 ` Brandon Williams
2016-09-15 22:08 ` Junio C Hamano [this message]
2016-09-15 22:28 ` Stefan Beller
2016-09-16 9:34 ` Heiko Voigt
2016-09-16 18:40 ` Brandon Williams
2016-09-17 0:59 ` [PATCH] ls-files: add pathspec matching for submodules Brandon Williams
2016-09-17 3:46 ` Junio C Hamano
2016-09-18 18:40 ` Brandon Williams
2016-09-19 17:00 ` Junio C Hamano
2016-09-19 17:26 ` Brandon Williams
2016-09-19 18:04 ` Junio C Hamano
2016-09-19 18:20 ` Brandon Williams
2016-09-19 18:22 ` Junio C Hamano
2016-09-19 18:30 ` Brandon Williams
2016-09-19 18:34 ` Junio C Hamano
2016-09-19 18:35 ` Brandon Williams
2016-09-19 18:52 ` [PATCH v2] " Brandon Williams
2016-09-19 23:21 ` Junio C Hamano
2016-09-20 16:30 ` Brandon Williams
2016-09-20 21:03 ` Brandon Williams
2016-09-21 17:12 ` Junio C Hamano
2016-09-21 17:49 ` Junio C Hamano
2016-09-19 18:18 ` [PATCH] " 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=xmqqr38klst6.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=bmwill@google.com \
--cc=git@vger.kernel.org \
--cc=hvoigt@hvoigt.net \
--cc=jens.lehmann@web.de \
--cc=pclouds@gmail.com \
--cc=sbeller@google.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).