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

From: Jens Lehmann <jens.lehmann@web.de>
Date: Jun 3, 2013, 21:47 UTC
Message-ID: <51AD0EEB.4020106@web.de>
In-Reply-To: <20130531194051.GC1072@serenity.lan>

Am 31.05.2013 21:40, schrieb John Keeping:

Show 30 quoted lines

> On Thu, May 30, 2013 at 09:23:40PM +0200, Jens Lehmann wrote:
>> Am 30.05.2013 01:58, schrieb Junio C Hamano:
>>> * jk/submodule-subdirectory-ok (2013-04-24) 3 commits
>>>   (merged to 'next' on 2013-04-24 at 6306b29)
>>>  + submodule: fix quoting in relative_path()
>>>   (merged to 'next' on 2013-04-22 at f211e25)
>>>  + submodule: drop the top-level requirement
>>>  + rev-parse: add --prefix option
>>>
>>>  Allow various subcommands of "git submodule" to be run not from the
>>>  top of the working tree of the superproject.
>>
>> The summary and status commands are looking good in this version
>> (they are now showing the submodule directory paths relative to
>> the current directory). Apart from that my other remarks from
>> gmane $221575 still seem to apply. And this series has only tests
>> for status, summary and add (and that just with an absolute URL),
>> I'd rather like to see a test for each submodule command (and a
>> relative add to) to document the desired behavior.
> 
> To summarize what I think are the outstanding issues from your email:
> 
> * Should '$sm_path' be relative in "submodule foreach"?
> * "submodule add" with a relative path
> * "submodule init" initializes all submodules
> * Tests
> 
> 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 ;-)

Show 5 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<---------------------

> "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.