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

On Fri, May 31, 2013 at 08:40:51PM +0100, John Keeping wrote:

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

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.

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

quoted

But I'm not sure if it's better to have another iteration of this
series or to address the open issues a follow-up series. Having
status, summary and add - at least with absolute URLs - lose the
toplevel requirement is already a huge improvement IMO. Opinions?

I think the only thing outstanding is tests.  I'm happy to add those as
a follow-up or in a re-roll.

I started looking at this over the weekend but didn't get time to get
something ready to be submitted.  I did find a couple of issues in
cmd_foreach that make me think this topic should be dropped when "next"
is rewound and held in pu waiting for a re-roll.