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 1/2] ls-files: adding support for submodules
Date: Tue, 27 Sep 2016 15:01:00 -0700	[thread overview]
Message-ID: <xmqqwphxknoj.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160927214854.GA180705@google.com> (Brandon Williams's message of "Tue, 27 Sep 2016 14:48:54 -0700")

Brandon Williams <bmwill@google.com> writes:

> Well maybe...I don't really know much about how the prefix interacts in
> every scenario but would what you describe still work if we are in a sub
> dir of the superproject (which contains other directorys and perhaps a
> submodule) and execute a --recurse-submodules command in the
> subdirectory?  I suspect we don't want to force users to be in the root
> directory of the project in order to use --recurse-submodules.

You need to remember "must be at the top" is relevant only to the
command that is invoked with --super-prefix, not the recursive one
that drives such a process.

Suppose your superproject is organized like so:

    - file-at-top
      a/file-in-A
      a/b (submodule)
      a/b/file-at-top-of-B
      c/  (submodule)
      c/file-at-top-of-C

If you are in a subdirectory of your superproject, say, a/,

    cd a && git ls-files --recurse-submodules -- "b*"

I would expect we would recurse into the submodule at "a/b" and find
"b/file-at-top-of-B".  What does the internal invocation to do so
would look like?  I would think "git -C b --super=b ls-files" that
is run from "a".

Your code would is already prepared to find "file-at-top-of-B" in
the index of the submodule, prepend "b/" to it and report the result
as "b/file-at-top-of-B" when such a call is made, I think.

Now, can you refer to c/ and c/file-at-top-of-C while sitting at a/?

    cd a && git ls-files --recurse-submodules -- "../c*"

would be the top-level invocation.  This would iterate over the
index of the superproject, trying to find what matches "c*" (or,
"../c*" relative to "a" i.e. where you are), find that 'c' that is a
submodule, and invoke "git -C ../c --super=../c ls-files"
internally, I would imagine.  I think your code is prepared to
accept this case as well.

In any case, the "must be at the top" does not come into the picture
at all for the end-user interaction, i.e. invocation of the command
that is told to recurse into submodules, so we'd be OK.


  reply	other threads:[~2016-09-27 22:01 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
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 [this message]
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=xmqqwphxknoj.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).