Re: What's cooking in git.git (May 2013, #09; Wed, 29)

From: John Keeping <john@keeping.me.uk>
Date: Jun 3, 2013, 22:23 UTC
Message-ID: <20130603222341.GL1072@serenity.lan>
In-Reply-To: <51AD0EEB.4020106@web.de>

On Mon, Jun 03, 2013 at 11:47:23PM +0200, Jens Lehmann wrote:

Show 11 quoted lines

> Am 31.05.2013 21:40, schrieb John Keeping:
> > The current version does make '$sm_path' relative in "submodule
> > foreach", although it's hard to spot because we have to leave doing so
> > until right before the "eval".
> 
> Yes. If I read the code correctly the submodule is cd'ed in before
> the foreach command is executed, so $sm_path should only be used for
> displaying info about where the command is executed anyway. Looks
> like your code is doing the right thing adjusting $sm_path to be
> relative to the directory the user is in. But a test showing that
> would really be nice ;-)

Agreed. I've also noticed that the legacy "path" variable hasn't been adjusted and the printing of the module paths does not make them relative. I'll fix them in the next version.

Show 27 quoted lines

> > I'm not sure what you mean about "submodule add" - the new version
> > treats the "path" argument as relative (providing it is not an absolute
> > path).  The "repository" argument is not changed by running from a
> > subdirectory but I think that's correct since it is documented as being
> > relative to the superproject's origin repository.
> 
> Sorry, I should have been more specific here. I saw that you did some
> changes to make "submodule add" do the right thing with relative paths,
> but the following change to t7406 does not work like I believe it
> should but instead makes the test fail:
> -------------------8<---------------------
> diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
> index a4ffea0..9766b9e 100755
> --- a/t/t7406-submodule-update.sh
> +++ b/t/t7406-submodule-update.sh
> @@ -559,7 +559,9 @@ test_expect_success 'add different submodules to the same pa
>  test_expect_success 'submodule add places git-dir in superprojects git-dir' '
>         (cd super &&
>          mkdir deeper &&
> -        git submodule add ../submodule deeper/submodule &&
> +        (cd deeper &&
> +         git submodule add ../../submodule submodule
> +        ) &&
>          (cd deeper/submodule &&
>           git log > ../../expected
>          ) &&
> -------------------8<---------------------

Ah, ok. I think this case is problematic because the repository argument is either relative to "remote.origin.url" or to the top of the working tree if there is no "origin" remote. I wonder if we should just die when a relative path is given for the repository and we're not at the top of the working tree.

Show 10 quoted lines

> > "submodule init" is behaving in the same way as "deinit" - if you say
> > "submodule init ." then it will only initialize submodules below the
> > current directory.  The difference is that "deinit" dies if it is not
> > given any arguments whereas "init" will initialize everything from the
> > top level down.  I'm not sure whether to change this; given the
> > direction "git add -u" is heading in for 2.0 I think the current
> > behaviour is the most consistent with the rest of Git.
> 
> I meant that both commands still print the submodule names from the
> top-level directory, not the one the user is in.

Will fix.