Mark Levedahl <mlevedahl@xxxxxxxxx> writes:
> Junio C Hamano wrote:
>> Ahh.
>>
>> Does that suggest the new configuration thing is only about the
>> "submodule update" command, not "remotes.default" that affects
>> how the non-submodule merge and fetch works?
>>
>>
> Yes - this patch set was inspired by the single question of "how do I
> avoid needing to define origin as opposed to a server-specific
> nickname now that I am using sub-modules?"
If it is truly only about "submodule update" then the change
seems too intrusive, especially "remotes.default" variable that
affects the way how fetch and merge works in situations that do
not involve submodules.
If it is not limited to "submodule update" but equally valid fix
to non-submodule situations, the changes to the other parts may
very well be justifiable, but that would mean your "Yes" is a
lie and instead should be "No, but these situations are helped
by these changes because...".
In any case, let's step back a bit.
Earlier you said in a response to Dscho that your servers are
named consistently across repositories. servername.foo.bar has
nickname servername everywhere.
If your top-level repository needs to access a specific server
"frotz.foo.bar" for updates, then you would have bootstrapped
the whole thing with:
$ git clone git://frotz.foo.bar/toplevel.git
and in that particular instance of the repository, the source
repository on frotz.foo.bar would have been known as 'origin',
right? I would not object if you also gave another nickname
'frotz' to the same repository for consistency across
developers.
If that is the case, I am wondering why your subprojects are not
pointing at the corresponding repository on that same
'frotz.foo.bar' machine as 'origin'. I suspect the reason is
that .gitmodules do not say 'frotz.foo.bar' but name some other
machine.
And in-tree .gitmodules can name only one URL, as it is project
global and shared by everybody. There is no escaping it.
At least as things were designed, "git submodule init" takes URL
recorded in .gitmodules as a hint, but this is for the user to
override in .git/config in the top-level. Maybe the UI to allow
this overriding is not easy enough to use, and your submodules
ended up pointing at wrong (from the machine's point of view)
URL as 'origin'. And perhaps that is the root cause of this
issue?
I am looking at the discussion on the list archive when we
discussed the initial design of .gitmodules:
http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47502
http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47548
http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47621
I do not think we are there yet, and suspect that the current
"git submodule init" does not give the user a chance to say "the
URL recorded in the in-tree .gitmodules corresponds to this URL
in this repository for administrative or network connectivity or
whatever reasons".
Maybe that is the real issue that we should be tackling. I
dunno.
Although I _think_ being able to use nickname other than
hardcoded 'origin' for fetch/merge is a good change, if my above
suspicion is correct, that change alone would not make the life
easier to people who _use_ submodules, as the need for them to
set up extra nicknames (like 'frotz') and configure the
submodule repositories to use that specific nickname instead of
'origin' would not change.
For communication purposes, I would agree with Dscho that the
name 'origin' that names different things for different people
is wrong and using specific name 'frotz' would solve
communication issues. But when using the repository and doing
actual work, wouldn't it be _much_ better if you can
consistently go to a repository on a random machine and always
can say 'origin' to mean the other repository this repository
usually gets new objects from (and sends its new objects to)?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
