On Tue, Aug 9, 2016 at 11:44 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> writes:
>
>> The way I understood and implemented it is
>>
>> here is a path, try to use it as an alternate; if that is not
>> an alternate, it's fine too; maybe warn about it, but carry
>> on with the operation.
>
> My expectation is without "maybe warn about it". And not adding it
> as an alternate (because it is not usable) is just "doing as I was
> told to do", nothing noteworthy. Because "do it only if you can" is
> an explicit instruction to the doer that the caller does not care
> about the outcome, I'd think there shouldn't be any warning, whether
> it is used or not. At the same time, if the caller wants to know
> the outcome, and using if-able as a way to say "I prefer to see it
> happen, but you do not have to panic if you can't", I'd think it is
> OK to give "info:" to report which of the two possible paths was
> taken in either case. Throwing a "warning:" only when it didn't do
> so does not make much sense to me.
I think this whole thing needs a new config variable to be set.
At the time of cloning you may run
git clone --recursive --reference <other-super-project-location>
or
git clone --recursive --reference-if-able <other-super-project-location>
or
git clone --recursive
The first two should trickle down to the submodules, i.e.
in the first case we maybe want to run
git config submodule.alternate=required-superproject &&
git submodule update --init --recurse
In the second case
git config submodule.alternate=optional-superproject &&
git submodule update --init --recurse
And in the third case we maybe only want to record
git config submodule.alternate=none # implicit by not setting it as well
git submodule update --init --recurse
Then later when we run
git submodule update
we have this option to know if a submodule alternate should be treated
as optional or required referenced as the existence
of the superprojects alternate (as a boolean indicator) is not enough of
an indicator what the user later wants.
>>
>> I see. This way the user is most informed.
>
> Yes, and if we were to go that route, "clone" without "-v" should
> not report which of the two it took. It is OK for "submodule" to
> look at what "clone" left as the result and do more intelligent
> reporting that is better suited for the context of the command.
>
>> The current implementation
>> of "submodule update --init" for start from scratch yields for example:
>>
>> Submodule 'foo' (<url>) registered for path 'foo'
>> Submodule 'hooks' (<url>) registered for path 'hooks'
>> Cloning into '/home/sbeller/super/foo'...
>> Cloning into '/home/sbeller/super/hooks'...
>> warning: Not using proposed alternate
>> /home/sbeller/super-reference/.git/modules/hooks/
>> Submodule path 'foo': checked out '7b41f3a413b46140b050ae5324cbbcdd467d2b3a'
>> Submodule path 'hooks': checked out '3acc14d10d26678eae6489038fe0d4dad644a9b4'
>>
>> so before this series we had 3 lines per submodule, and with this series
>> we get a 4th line for the unusual case.
>>
>> You would prefer to see always 4 lines per submodule?
>
> If the user says "--recursive --reference", then the user probably
> deserves to be notified. As I said (eh, rather, as I wanted to say
> but failed to say so), I do not have a strong preference either way.
With a new config option we can trigger the notifications based on that as well.
"required superproject" would die when the submodule alternate is not there,
and the "optional superproject" would always state if it found an alternate.
Thanks,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html