From: Marc Branchaud <marcnarc@xiplink.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jens Lehmann <Jens.Lehmann@web.de>,
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: Mon, 06 Jun 2011 17:23:23 -0400 [thread overview]
Message-ID: <4DED454B.1050105@xiplink.com> (raw)
In-Reply-To: <7vei368ylj.fsf@alter.siamese.dyndns.org>
On 11-06-06 05:00 PM, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Am 05.06.2011 20:27, schrieb Junio C Hamano:
>>> If you think about "absense of the remote in the superproject means the
>>> project originates from here", what you are doing in step 3. is to
>>> changing the origin of these set of projects. After changing the origin of
>>> these set of projects, isn't "git submodule sync" an established way to
>>> adjust to the change? I was hoping that that would update .git/config in
>>> step 3. so you wouldn't have the problem in step 4. at all.
>>
>> Thanks for explaining that in detail, I think I do get it now.
>
> 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.
Well, Jens's changes do remove the error I encountered, and they also do what
I was expecting in the original context I was in when I started this thread.
So I think this is a definite improvement.
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.
M.
next prev parent reply other threads:[~2011-06-06 21:23 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 [this message]
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=4DED454B.1050105@xiplink.com \
--to=marcnarc@xiplink.com \
--cc=Jens.Lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hordp@cisco.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 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.