Stefan Beller [off-list ref] 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.
The way you write this response I think you have a slightly
different understanding of what the -if-able ought to do?
When --reference is given, only the superproject should
borrow and the -if-able, may allow submodules to also borrow?
I have no idea what this sentence means.
quoted
I have a very strong opinion what should happen when the end-user
facing command is "git submodule", but if I have to choose, I would
prefer to see "git submodule update" tell what it did with "info:"
either case, i.e. "info: borrowing from ... because the superproject
borrows from there", and "info: not borrowing from ... even though
the superproject borrows from there".
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.
On Tue, Aug 9, 2016 at 11:44 AM, Junio C Hamano [off-list ref] wrote:
Stefan Beller [off-list ref] writes:
quoted
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.
quoted
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.
quoted
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