From: Junio C Hamano <gitster@pobox•com>
To: Stefan Beller <sbeller@google•com>
Cc: "git\@vger.kernel.org" <git@vger•kernel.org>,
Duy Nguyen <pclouds@gmail•com>,
Jens Lehmann <Jens.Lehmann@web•de>,
Jacob Keller <jacob.keller@gmail•com>,
Eric Sunshine <sunshine@sunshineco•com>
Subject: Re: [PATCHv3 5/5] submodule--helper clone: lose the extra prefix option
Date: Fri, 25 Mar 2016 16:15:13 -0700 [thread overview]
Message-ID: <xmqqegay175q.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAGZ79kbbVN4kQyQoTk+3o5yPZPAdGULtOhKisOLUf9-u7ssh7A@mail.gmail.com> (Stefan Beller's message of "Fri, 25 Mar 2016 16:02:11 -0700")
Stefan Beller <sbeller@google•com> writes:
>> Of course by using -C, you might notice that repo/sub/untracked does
>> not exist, but that is not a proper error checking---what if the
>> submodule at repo/sub does have a directory with that name? IOW,
>> the computation that gave repo/sub/untracked instead of ../untracked
>> is wrong and using -C would not make it right.
>
> There is no explicit computation of repo/sub/untracked, but it would happen
> implicitely in the -C case as we'd be in the repo/sub and try to chdir
> to 'untracked'
> (interpreted as a relative path)
You are looking at repo/sub/untracked that does not have anything to
do with the reality, and it does not matter if you have an explicit
code to construct "char *" that points at such a pathname, or it
happens implicitly. Looking for 'untracked' directory after going
inside 'repo/sub/untracked' is simply wrong, just like looking for
'sub/untracked' diretory while staying at 'repo/' is wrong.
If anything, ../tracked might have some relevance to the reality but
nobody is computing it, which may be a bug in "git submodule" if
<cmd> wants to have an access to the original place.
In either case, that is true with either -C/--prefix, no?
>> And if you clear the prefix you originally obtained in calling
>> script "git submodule", which is "untracked/", even if <cmd> somehow
>> wanted to refer to the "file" in that directory, the only clue to do
>> so is forever lost. Again, this is unrelated to -C/--prefix, but
>> that is what the patch 2 in the original series (which was rolled
>> into patch 1 in the update) was about.
>
> As of now this file would also be lost I would assume, as it is unclear
> which repository you refer to.
>
> If you are in the "subsub" submodule and know that the $wt_prefix=untracked,
> you still don't know if the original command was invoked from the root super
> project or the intermediate submodule.
I am talking about a case where
cd repo
cd untracked
git submodule <cmd> --recurse-submodules --read-from=file
wants to run <cmd>, using information stored in repo/untracked/file,
and work on submodules repo/sub and repo/sub/subsub. The reference
to the original location somehow needs to be carried through if we
wanted to allow this kind of thing.
>> So I am not sure what the value of using -C is. At least that
>> "example from before" does not serve as a good justification.
And I do not think your reply does not change anything with respect
to this statement.
next prev parent reply other threads:[~2016-03-25 23:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-25 18:39 [PATCHv3 0/5] submodule helper: cleanup prefix passing Stefan Beller
2016-03-25 18:39 ` [PATCHv3 1/5] submodule: prepare recursive path from non root directory Stefan Beller
2016-03-25 19:21 ` Junio C Hamano
2016-03-25 18:39 ` [PATCHv3 2/5] submodule--helper list: lose the extra prefix option Stefan Beller
2016-03-25 18:39 ` [PATCHv3 3/5] submodule update: add test for recursive from non root dir Stefan Beller
2016-03-25 18:39 ` [PATCHv3 4/5] submodule sync: test syncing one submodule Stefan Beller
2016-03-25 18:39 ` [PATCHv3 5/5] submodule--helper clone: lose the extra prefix option Stefan Beller
2016-03-25 19:41 ` Junio C Hamano
2016-03-25 20:54 ` Junio C Hamano
2016-03-25 22:09 ` Stefan Beller
2016-03-25 22:39 ` Junio C Hamano
2016-03-25 23:02 ` Stefan Beller
2016-03-25 23:15 ` Junio C Hamano [this message]
2016-03-25 23:51 ` Stefan Beller
2016-03-28 16:56 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqegay175q.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=Jens.Lehmann@web$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=jacob.keller@gmail$(echo .)com \
--cc=pclouds@gmail$(echo .)com \
--cc=sbeller@google$(echo .)com \
--cc=sunshine@sunshineco$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox