From: Junio C Hamano <hidden> Date: 2016-06-15 22:51:25
Jens Lehmann [off-list ref] writes:
Am 05.06.2011 20:27, schrieb Junio C Hamano:
quoted
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.
From: Marc Branchaud <hidden> Date: 2016-06-15 22:51:25
On 11-06-06 05:00 PM, Junio C Hamano wrote:
Jens Lehmann [off-list ref] writes:
quoted
Am 05.06.2011 20:27, schrieb Junio C Hamano:
quoted
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.
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.
That's why I started with an improved error message and documentation ;-)
quoted
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.
Thanks.
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.
Maybe Phil's opinion could be helpful here as he seems to be a heavy user of
relative submodule urls.
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?
From: Phil Hord <hidden> Date: 2016-06-15 22:51:26
/(Pardon the duplicate; sending this again from my clean MUA.)
/
Sometime last week, Marc Branchaud wrote:
I believe your case works smoothly only because in your super-project
you're careful to make sure you have checked out a branch that
remotely tracks a something in remotes/public. If you checked out a
branch that tracks a different remote you'd get different results.
This seems fragile to me.
Well, I definitely wasn't careful, but in fact I _was_ on a
remote-tracking branch. The fact that 'git submodule add' is dependent
on the currently-checked-out branch is a surprise to me.
When you tried the detached-HEAD scenario, did you get URLs for
"public:git/sub" or "origin:git/sub"? Does "origin" just happen to be
the remote you want to use in any case?
Yes, origin happens to be the remote I want to use. Actually, any of
the remotes would be fine with me because in this case I want to push to
all of them eventually. The scenario I was working on was where I am
creating a new repository and new submodules to go in it. All of my
remotes are clones of my repo collection.
git remote -v
git02 git02:foo/tss.git (fetch)
git02 git02:foo/tss.git (push)
origin public:bar/tss (fetch)
origin public:bar/tss (push)
My fundamental point is that "git submodule add" seems to do confusing
things with relative paths. Maybe all that's needed is to clarify the
documentation. I'll post a patch.
I definitely agree that 'submodule add' does confusing and unexpected
things. I only got it to work by carefully contriving the exact steps
required to make it work. Editing .gitmodules directly would have been
much simpler.
Clarifying the documentation is a good first step. But now that you've
made me look at this more closely, I see there is much more to complain
about and, hopefully, get fixed.
I've run out of time today, though. I'll follow up with another email
on this thread tomorrow.
Thanks for stirring this pot.
Phil