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: > > 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". > > 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. > > > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html