All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Hord <hordp@cisco.com>
To: Marc Branchaud <marcnarc@xiplink.com>
Cc: Jens Lehmann <Jens.Lehmann@web.de>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] submodule add: improve message when resolving a relative url fails
Date: Tue, 31 May 2011 18:04:15 -0400	[thread overview]
Message-ID: <4DE565DF.7050207@cisco.com> (raw)
In-Reply-To: <4DE5561C.3010200@xiplink.com>

On 05/31/2011 04:57 PM, Marc Branchaud wrote:
> Thanks for the cogent explanation & patch.  I think the message could be
> improved a bit:
>
> 	Cannot resolve "../sub" relative to this repository's "origin"
> 	remote: The remote's URL is not set in .git/config
>
> However, overall I think this is a pretty fragile way to handle relative
> paths.  Consider:
>
>  - The super-repo must be a clone in order for this to work at all.

Yes, but that constraint (mostly) makes sense to me.  But if 'git
submodule add' did not initialize .git/config, this constraint could be
dropped.

>  - The super-repo cannot be checked out on a detached HEAD.

Why do you think that?  I just tried this and it worked fine for me.  I
can't think of a reason for it to fail.

>  - The current code rewrites the URL so that any relative path is either
>    rejected or munged into an absolute remote URL.

I don't see the URL getting munged away from being relative.  Can you
point to an example?

> It seems to me that this feature will only work in a fairly narrow set of
> circumstances, and even when it does work it's likely to do something
> unexpected (think of a super-repo with several remotes).

I use it this way with several remotes. 

> Back when Junio accepted the original patch, he said "If you maintain and
> serve a set related projects you need to give the users a single URL (per
> where the user is and how to reach the server)."  I'm not sure I understand
> that:  Why would the users be adding their own submodules to the
> superproject?  Wouldn't the superproject define the submodules in for them?
I am a user.  I admin a super-project for other users.  This project
lives at three remotes, remotes/public, remotes/shared and remotes/build. 

I add a new submodule to the superproject like this:

   mkdir sub && cd sub && git init
   cd ..
   git submodule add ../sub sub

This results in the new submodule being inserted into my .gitmodules
file and my .git/config:

   tail -3 .gitmodules
   [submodule "sub"]
       path = sub
       url = ../sub

   tail -2 .git/config
   [submodule "sub"]
       url = public:git/sub

I do have to make sure to push my submodule to the correct location on
each remote before pushing my new .gitmodules.

But the exact same commands work for me if I do this first and then do
'git submodule add ../sub' afterwards. 

So, I don't understand your objections.  Do you understand my use case
any better?

Phil

  parent reply	other threads:[~2011-05-31 22:04 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-30 21:51 [PATCH 0/2] Tests for some submodule corner cases Marc Branchaud
2011-05-30 21:51 ` [PATCH 1/2] Added a test for "submodule add" using a ../relative/path/to/the/submodule/repo Marc Branchaud
2011-05-30 21:51 ` [PATCH 2/2] Added a test for "submodule status" when the submodule's working directory has deleted files Marc Branchaud
2011-05-31 19:30 ` [PATCH 0/2] Tests for some submodule corner cases Jens Lehmann
2011-05-31 20:00   ` [PATCH] submodule add: improve message when resolving a relative url fails Jens Lehmann
2011-05-31 20:57     ` Marc Branchaud
2011-05-31 21:34       ` [PATCH v2] " Jens Lehmann
2011-05-31 22:04       ` Phil Hord [this message]
2011-06-01 15:55         ` [PATCH] " Marc Branchaud
2011-07-27 19:00           ` Phil Hord
2011-07-29 20:10             ` Marc Branchaud
2011-05-31 23:23       ` Junio C Hamano
2011-06-01 15:56         ` [PATCH] Clarified how "git submodule add" handles relative paths Marc Branchaud
2011-06-01 16:59           ` Junio C Hamano
2011-06-01 19:55             ` Jens Lehmann
2011-06-02 17:14               ` Junio C Hamano
2011-06-03 19:51                 ` Jens Lehmann
2011-06-03 23:16                   ` Junio C Hamano
2011-06-04  2:23                     ` Mark Levedahl
2011-06-04 15:39                       ` Jens Lehmann
2011-06-04 16:19                     ` Jens Lehmann
2011-06-05 18:27                   ` Junio C Hamano
2011-06-06 19:56                     ` [PATCH 0/3] submodule add: allow relative repository path even when no url is set Jens Lehmann
2011-06-06 19:57                       ` [PATCH 1/3] submodule add: test failure when url is not configured in superproject Jens Lehmann
2011-06-06 19:58                       ` [PATCH 2/3] submodule add: allow relative repository path even when no url is set Jens Lehmann
2011-06-06 20:49                         ` [PATCH 0/2] Improve "git submodule add" documentation Marc Branchaud
2011-06-06 20:49                           ` [PATCH 1/2] More precisely described how "git submodule add" handles relative submodule URLs Marc Branchaud
2011-06-06 20:49                           ` [PATCH 2/2] Moved paragraph describing the utility of " Marc Branchaud
2011-06-06 19:58                       ` [PATCH 3/3] submodule add: clean up duplicated code Jens Lehmann
2011-06-06 21:00                       ` [PATCH 0/3] submodule add: allow relative repository path even when no url is set Junio C Hamano
2011-06-06 21:23                         ` Marc Branchaud
2011-06-06 21:39                           ` Jens Lehmann
2011-06-07 21:03                           ` Jens Lehmann
2011-06-08 13:16                             ` Phil Hord
2011-06-02 14:21             ` [PATCHv2] Clarified how "git submodule add" handles relative paths Marc Branchaud
2011-05-31 21:06   ` [PATCH 0/2] Tests for some submodule corner cases Marc Branchaud
2011-05-31 21:26     ` Jens Lehmann
2011-06-01 16:11       ` Marc Branchaud
2011-06-01 17:44         ` Junio C Hamano
2011-06-01 19:26         ` Jens Lehmann

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=4DE565DF.7050207@cisco.com \
    --to=hordp@cisco.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=marcnarc@xiplink.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 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.