All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Voigt <hvoigt@hvoigt.net>
To: John Keeping <john@keeping.me.uk>
Cc: Jens Lehmann <Jens.Lehmann@web.de>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: Re: Re: What's cooking in git.git (May 2013, #09; Wed, 29)
Date: Tue, 4 Jun 2013 21:17:17 +1000	[thread overview]
Message-ID: <20130604111717.GA306@book.hvoigt.net> (raw)
In-Reply-To: <20130604081045.GM1072@serenity.lan>

On Tue, Jun 04, 2013 at 09:10:45AM +0100, John Keeping wrote:
> On Tue, Jun 04, 2013 at 03:29:51PM +1000, Heiko Voigt wrote:
> > On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wrote:
> > > > 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<---------------------
> > > 
> > > Ah, ok.  I think this case is problematic because the repository
> > > argument is either relative to "remote.origin.url" or to the top of the
> > > working tree if there is no "origin" remote.  I wonder if we should just
> > > die when a relative path is given for the repository and we're not at
> > > the top of the working tree.
> > 
> > Why not behave as if we are at the top of the working tree for relative
> > paths? If there is an origin remote thats fine. If there is no origin
> > remote you could warn that the path used is taken relative from the root
> > of the superproject during add. What do you think?
> 
> That's what the patch currently queued on "pu" does, which Jens wants to
> change, isn't it?

True I did not realize this when reading it the first time. But I think
we should still not die when in a subdirectory. After all this series is
trying to archive that the submodule command works in subdirectories
seamlessly right? So you probably want to translate a relative path
without "origin" remote given from a subdirectory to the superproject
level and use that. Then you do not have to die.

Cheers Heiko

  reply	other threads:[~2013-06-04 11:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-29 23:58 What's cooking in git.git (May 2013, #09; Wed, 29) Junio C Hamano
2013-05-30  9:47 ` Thomas Rast
2013-05-30  9:56   ` Ramkumar Ramachandra
2013-06-02 23:44   ` Junio C Hamano
2013-05-30 19:18 ` Jens Lehmann
2013-06-02 18:50   ` Junio C Hamano
2013-06-03 21:27     ` Jens Lehmann
2013-07-01 22:05       ` Junio C Hamano
2013-05-30 19:23 ` Jens Lehmann
2013-05-31 19:40   ` John Keeping
2013-06-03 14:54     ` John Keeping
2013-06-03 15:30       ` Junio C Hamano
2013-06-03 21:47     ` Jens Lehmann
2013-06-03 22:23       ` John Keeping
2013-06-04  5:29         ` Heiko Voigt
2013-06-04  8:10           ` John Keeping
2013-06-04 11:17             ` Heiko Voigt [this message]
2013-06-04 12:48               ` John Keeping
2013-06-04 21:39                 ` Jens Lehmann
2013-06-04 22:04                   ` John Keeping
2013-06-04 22:57                 ` Re: " Phil Hord
2013-06-05  8:19                   ` John Keeping
2013-05-31  6:16 ` Øystein Walle

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=20130604111717.GA306@book.hvoigt.net \
    --to=hvoigt@hvoigt.net \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=john@keeping.me.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.