Lars Hjemli [off-list ref] writes:
This teaches git-submodule to check module.*.path when looking for the
config for a submodule path. If no match is found it falls back to the
current behaviour (module.$path).
I have a feeling that it might be much less troublesome in the
longer term to admit that module.$path was a mistake and support
only one format; wouldn't trying to support both leave ambiguity
and confusion?
Hi,
On Sat, 9 Jun 2007, Junio C Hamano wrote:
Lars Hjemli [off-list ref] writes:
quoted
This teaches git-submodule to check module.*.path when looking for the
config for a submodule path. If no match is found it falls back to the
current behaviour (module.$path).
I have a feeling that it might be much less troublesome in the longer
term to admit that module.$path was a mistake and support only one
format; wouldn't trying to support both leave ambiguity and confusion?
Just my 2cents: git-submodule is not yet in any released version. So let's
fix things early. In our world, it's not like you lose face when you have
to admit mistakes. (Instead, you lose face when you refuse to fix them.)
Ah, if only politics learnt from our world...
Ciao,
Dscho
On 6/10/07, Junio C Hamano [off-list ref] wrote:
Lars Hjemli [off-list ref] writes:
quoted
This teaches git-submodule to check module.*.path when looking for the
config for a submodule path. If no match is found it falls back to the
current behaviour (module.$path).
I have a feeling that it might be much less troublesome in the
longer term to admit that module.$path was a mistake and support
only one format;
Hmm, what the patch does should match what is described in
http://article.gmane.org/gmane.comp.version-control.git/48879
except that I've kept [module] instead of renaming it to [submodule].
But my wording ("module.$path") might be disconcerting :)
Fwiw: I do admit that the [path "path"] construct was a mistake.
--
larsh