git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Keeping <john@keeping.me.uk>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
	Jens Lehmann <Jens.Lehmann@web.de>,
	Heiko Voigt <hvoigt@hvoigt.net>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v2 2/2] submodule: drop the top-level requirement
Date: Thu, 18 Apr 2013 15:56:18 +0100	[thread overview]
Message-ID: <20130418145617.GA2278@serenity.lan> (raw)
In-Reply-To: <CALkWK0==bnrRJDk1daANoZOOVLwZOPM+YhwOZs7yimoYBoyXyA@mail.gmail.com>

On Thu, Apr 18, 2013 at 08:16:42PM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> > Use the new rev-parse --prefix option to process all paths given to the
> > submodule command, dropping the requirement that it be run from the
> > top-level of the repository.
> 
> Yay!
> 
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index 79bfaac..bbf7983 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -112,6 +115,7 @@ resolve_relative_url ()
> >  #
> >  module_list()
> >  {
> > +       eval "set $(git rev-parse --sq --prefix "$wt_prefix" -- "$@")"
> 
> Nit: Why not use "--" to disambiguate between options and arguments,
> like you showed in your intended usage?

Erm... it does.  What's before "$@"?

Ah, you mean after "set".  In this case, rev-parse will keep the "--" we
supply to it, so we get that from there and do not want to give set an
extra one.

> So, this essentially converts all the paths specified in "$@" to
> toplevel-relative paths.  Beautiful, as this is practically the only
> change you require in each function.
> 
> > +       sm_path="$wt_prefix$sm_path"
> 
> Wait, isn't sm_path the value of submodule.<name>.path in .gitmodules?
>  Why does it need to be prefixed?

I think you've lost too much context here.  This is in cmd_add and at
this point sm_path holds the argument supplied by the user, which we
must adjust as it will be relative to the current directory.

We should probably be testing for an absolute path here though.

> > @@ -942,6 +948,7 @@ cmd_summary() {
> >         fi
> >
> >         cd_to_toplevel
> > +       eval "set $(git rev-parse --sq --prefix "$wt_prefix" -- "$@")"
> 
> Um, what about other functions?  Yeah, it looks like all of them
> except this one call module_list().

Exactly.  Apart from this and cmd_add everything uses module_list.

> > diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> > index ff26535..7795f21 100755
> > --- a/t/t7400-submodule-basic.sh
> > +++ b/t/t7400-submodule-basic.sh
> > @@ -212,6 +212,23 @@ test_expect_success 'submodule add with ./, /.. and // in path' '
> >         test_cmp empty untracked
> >  '
> >
> > +test_expect_success 'submodule add in subdir' '
> > +       echo "refs/heads/master" >expect &&
> > +       >empty &&
> 
> Nit: Use : >empty.  It's clearer.
> 
> > +       (
> > +               mkdir addtest/sub &&
> 
> Why is the mkdir inside the subshell?  The next statement (cd) onwards
> should be in the subshell, to save you cd'ing back.
>
> > +               cd addtest/sub &&
> > +               git submodule add "$submodurl" ../realsubmod3 &&
> > +               git submodule init
> > +       ) &&
> > +
> > +       rm -f heads head untracked &&
> 
> Huh?  What is this in the middle?  The next statement (call to
> inspect) write-truncates them anyway, so this is unnecessary.

I just followed the surrounding tests here.  I think it's better for
follow the pattern of the surrounding code here than get this one test
perfect.  A cleanup can follow on top if someone wants to do it.

  reply	other threads:[~2013-04-18 14:56 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-07 19:55 [RFC/PATCH 0/2] submodule: drop the top-level requirement John Keeping
2013-04-07 19:55 ` [PATCH 1/2] rev-parse: add --filename-prefix option John Keeping
2013-04-07 22:14   ` Jonathan Nieder
2013-04-08  8:31     ` John Keeping
2013-04-08 15:07       ` Junio C Hamano
2013-04-08 17:36         ` John Keeping
2013-04-08 18:11           ` Junio C Hamano
2013-04-07 19:55 ` [PATCH 2/2] submodule: drop the top-level requirement John Keeping
2013-04-07 20:15 ` [RFC/PATCH 0/2] " Jens Lehmann
2013-04-09 20:29 ` [PATCH v2 " John Keeping
2013-04-09 20:29   ` [PATCH v2 1/2] rev-parse: add --filename-prefix option John Keeping
2013-04-09 20:57     ` Junio C Hamano
2013-04-09 21:28       ` John Keeping
2013-04-09 21:33         ` Junio C Hamano
2013-04-18 14:28     ` Ramkumar Ramachandra
2013-04-18 14:42       ` John Keeping
2013-04-09 20:29   ` [PATCH v2 2/2] submodule: drop the top-level requirement John Keeping
2013-04-09 21:00     ` Junio C Hamano
2013-04-09 21:29       ` John Keeping
2013-04-18 14:46     ` Ramkumar Ramachandra
2013-04-18 14:56       ` John Keeping [this message]
2013-04-18 19:50   ` [PATCH v3 0/2] " John Keeping
2013-04-18 19:50     ` [PATCH v3 1/2] rev-parse: add --prefix option John Keeping
2013-04-19  9:53       ` Ramkumar Ramachandra
2013-04-19 10:22         ` John Keeping
2013-04-19 11:15           ` Ramkumar Ramachandra
2013-04-19 11:25             ` John Keeping
2013-04-19 11:29               ` Ramkumar Ramachandra
2013-04-18 19:50     ` [PATCH v3 2/2] submodule: drop the top-level requirement John Keeping
2013-04-18 22:40       ` Junio C Hamano
2013-04-19  7:46         ` John Keeping
2013-04-19 16:45           ` Junio C Hamano
2013-04-19 19:23             ` Johannes Sixt
2013-04-19 21:03               ` Junio C Hamano
2013-04-24  8:15                 ` [PATCH] submodule: fix quoting in relative_path() John Keeping
2013-04-24 16:21                   ` Junio C Hamano
2013-04-24 16:28                     ` John Keeping
2013-04-24 19:12                       ` Johannes Sixt
2013-04-18 23:54       ` [PATCH v3 2/2] submodule: drop the top-level requirement Eric Sunshine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130418145617.GA2278@serenity.lan \
    --to=john@keeping.me.uk \
    --cc=Jens.Lehmann@web.de \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hvoigt@hvoigt.net \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).