From: Jens Lehmann <Jens.Lehmann@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Marc Branchaud <marcnarc@xiplink.com>,
git@vger.kernel.org, Mark Levedahl <mlevedahl@gmail.com>,
Phil Hord <hordp@cisco.com>
Subject: Re: [PATCH 0/3] submodule add: allow relative repository path even when no url is set
Date: Tue, 07 Jun 2011 23:03:58 +0200 [thread overview]
Message-ID: <4DEE923E.9030208@web.de> (raw)
In-Reply-To: <4DED454B.1050105@xiplink.com>
Am 06.06.2011 23:23, schrieb Marc Branchaud:
> On 11-06-06 05:00 PM, Junio C Hamano wrote:
>> I actually still have a feeling that I may be missing something from the
>> discussion. While I do like a solution that lifts existing limitation to
>> allow workflows that were hitherto impossible, that only makes sense when
>> the newly allowed workflow makes sense and useful, and when the lifted
>> limitation was not protecting some silly mistakes from getting made.
>>
>> I _think_ our last exchange gave me a fuzzy confirmation that we are not
>> lifting a useful limitation, but I still do not know if the new workflow
>> matches the workflow Marc (who kicked off this thread) wanted to use. I
>> think it does match the set-up Phil Hord mentioned in an earlier message,
>> though.
After thinking about this issue some more I think the change is good. We
only affect relative urls and obviously don't change the case where the
url is already set in the superproject (that case stays like it is and
users like Phil seem to like it that way).
For the case where the url is not set I see two use cases: The first for
people who would like to keep their submodules local (like me and Marc):
the new behavior enables us to use a relative path too, so we are happy.
Then there are those who want to have a submodule relative to the super-
projects url: they won't get an error anymore when using a relative url
without having a default remote in the superproject. But that is easily
fixed later by doing a "submodule sync" when they recognize that fact,
just like Junio explained.
> There may still be a lingering niggle where git might do something the user
> doesn't expect. For example, git might create a submodule out of
> git://origin/foo.git instead of the local ../foo.git. You have to be paying
> attention to git's output to notice that difference, and I could see where a
> user might get tripped up. But IMO improving this can be done independently
> of Jens's patches.
This behavior exists for some time and is not changed by the patches in
question. But maybe when this patch is applied and people get used to
relative paths for local submodules that might become an issue when they
run into it. But I surely won't have an upstream defined for a superproject
I want to add a local submodule too, so I doubt that.
Or am I still missing something?
next prev parent reply other threads:[~2011-06-07 21: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 ` [PATCH] " Phil Hord
2011-06-01 15:55 ` 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 [this message]
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=4DEE923E.9030208@web.de \
--to=jens.lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hordp@cisco.com \
--cc=marcnarc@xiplink.com \
--cc=mlevedahl@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).