Re: [PATCHv3 5/5] submodule--helper clone: lose the extra prefix option

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 25, 2016, 23:15 UTC
Message-ID: <xmqqegay175q.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kbbVN4kQyQoTk+3o5yPZPAdGULtOhKisOLUf9-u7ssh7A@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 10 quoted lines

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

Show 13 quoted lines

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