From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Keeping Subject: Re: What's cooking in git.git (May 2013, #09; Wed, 29) Date: Mon, 3 Jun 2013 15:54:05 +0100 Message-ID: <20130603145405.GJ1072@serenity.lan> References: <7va9ndqqyf.fsf@alter.siamese.dyndns.org> <51A7A73C.6070103@web.de> <20130531194051.GC1072@serenity.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Junio C Hamano , git@vger.kernel.org To: Jens Lehmann X-From: git-owner@vger.kernel.org Mon Jun 03 16:54:22 2013 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UjW9K-00086a-97 for gcvg-git-2@plane.gmane.org; Mon, 03 Jun 2013 16:54:18 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758097Ab3FCOyP (ORCPT ); Mon, 3 Jun 2013 10:54:15 -0400 Received: from coyote.aluminati.org ([72.9.247.114]:46330 "EHLO coyote.aluminati.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757501Ab3FCOyO (ORCPT ); Mon, 3 Jun 2013 10:54:14 -0400 Received: from localhost (localhost [127.0.0.1]) by coyote.aluminati.org (Postfix) with ESMTP id A457360653F; Mon, 3 Jun 2013 15:54:13 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at caracal.aluminati.org X-Spam-Flag: NO X-Spam-Score: -12.9 X-Spam-Level: X-Spam-Status: No, score=-12.9 tagged_above=-9999 required=6.31 tests=[ALL_TRUSTED=-1, ALUMINATI_LOCAL_TESTS=-10, BAYES_00=-1.9] autolearn=ham Received: from coyote.aluminati.org ([127.0.0.1]) by localhost (coyote.aluminati.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfDvLpda70Kc; Mon, 3 Jun 2013 15:54:13 +0100 (BST) Received: from pichi.aluminati.org (pichi.aluminati.org [10.0.16.50]) by coyote.aluminati.org (Postfix) with ESMTP id 1123360652A; Mon, 3 Jun 2013 15:54:12 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by pichi.aluminati.org (Postfix) with ESMTP id E3640161E424; Mon, 3 Jun 2013 15:54:12 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at aluminati.org Received: from pichi.aluminati.org ([127.0.0.1]) by localhost (pichi.aluminati.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXYRylarAsyS; Mon, 3 Jun 2013 15:54:12 +0100 (BST) Received: from serenity.lan (tg2.aluminati.org [10.0.7.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pichi.aluminati.org (Postfix) with ESMTPSA id 1F0D4161E461; Mon, 3 Jun 2013 15:54:07 +0100 (BST) Content-Disposition: inline In-Reply-To: <20130531194051.GC1072@serenity.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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.