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

Am 31.05.2013 21:40, schrieb John Keeping:

On Thu, May 30, 2013 at 09:23:40PM +0200, Jens Lehmann wrote:

quoted

Am 30.05.2013 01:58, schrieb Junio C Hamano:

quoted

* 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 ;-)

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.