Re: [PATCH 2/3] Add gitmodules(5)

"Lars Hjemli" [off-list ref] writes:

Hmm, maybe I should just rename [module] to [submodule] right now? It
would be better forward compatible with the proposed extension, it
would 'harmonize' the section names used in .gitmodules and
.git/config, and it would offer a clean break from what's currently
supported in 'master'.

Yes, the difference between '[submodule]' vs '[module]' in
.git/config and .gitmodules confused me while looking at your
latest patch series.  I am in favor of unifying them.  We would
not be breaking any released version if we harmonize them now.

On 6/10/07, Junio C Hamano [off-list ref] wrote:

"Lars Hjemli" [off-list ref] writes:

quoted

Hmm, maybe I should just rename [module] to [submodule] right now? It
would be better forward compatible with the proposed extension, it
would 'harmonize' the section names used in .gitmodules and
.git/config, and it would offer a clean break from what's currently
supported in 'master'.

Yes, the difference between '[submodule]' vs '[module]' in
.git/config and .gitmodules confused me while looking at your
latest patch series.  I am in favor of unifying them.  We would
not be breaking any released version if we harmonize them now.

Good, then I'll do it that way. And I'll drop the "unless otherwise
noted, name=path" behaviour. If we later decide it would be useful we
can always "re-add" it.

--
larsh

On Sun, Jun 10, 2007 at 11:14:27PM +0200, Lars Hjemli wrote:

And I'll drop the "unless otherwise
noted, name=path" behaviour. If we later decide it would be useful we
can always "re-add" it.

So every (sub)module subsection will have to have a path element?
Why?

skimo

On 6/11/07, Sven Verdoolaege [off-list ref] wrote:

On Sun, Jun 10, 2007 at 11:14:27PM +0200, Lars Hjemli wrote:

quoted

And I'll drop the "unless otherwise
noted, name=path" behaviour. If we later decide it would be useful we
can always "re-add" it.

So every (sub)module subsection will have to have a path element?

Yes

Why?

It addresses Junio's concern about ambiguity and confusion. And it
felt like the 'safe choice', i.e. starting out with a strict rule and
possibly loosen it later on is a lot easier than starting loose and
then trying to make it stricter.

Btw: adding support for the optional path specification on top of my
latest patch-series is trivial:

diff --git a/git-submodule.sh b/git-submodule.sh
index 89a3885..297272b 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh

@@ -34,8 +34,7 @@ module_name()
 {
        name=$(GIT_CONFIG=.gitmodules git-config --get-regexp

'^submodule\..*\.path$' "$1" |
        sed -nre 's/^submodule\.(.+)\.path .+$/\1/p')
-       test -z "$name" &&
-       die "No submodule mapping found in .gitmodules for path '$path'"
+       test -z "$name" && name="$path"
        echo "$name"
 }

--
larsh

On Mon, Jun 11, 2007 at 12:47:43PM +0200, Lars Hjemli wrote:

On 6/11/07, Sven Verdoolaege [off-list ref] wrote:

quoted

On Sun, Jun 10, 2007 at 11:14:27PM +0200, Lars Hjemli wrote:

quoted

And I'll drop the "unless otherwise
noted, name=path" behaviour. If we later decide it would be useful we
can always "re-add" it.

So every (sub)module subsection will have to have a path element?

Yes

quoted

Why?

It addresses Junio's concern about ambiguity and confusion.

Junio, is this really what you meant?

Linus even advocated removing the mapping completely
(http://article.gmane.org/gmane.comp.version-control.git/48871),
but I wouldn't go that far.

skimo