Hi,
Robert Dailey wrote:
> The documentation wasn't 100% clear on this, but I'm assuming by
> "remote origin", it says that the relative URL is relative to the
> actual remote *named* origin (and it is not using origin as just a
> general terminology).
Thanks for reporting. The remote used is the default remote that "git
fetch" without further arguments would use:
get_default_remote () {
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch="${curr_branch#refs/heads/}"
origin=$(git config --get "branch.$curr_branch.remote")
echo ${origin:-origin}
}
The documentation is wrong. git-fetch(1) doesn't provide a name for
this thing. Any ideas for wording?
> Is there a way to specify (on a per-clone basis) which named remote
> will be used to calculate the URL for submodules?
Currently there isn't, short of reconfiguring the remote used by
default by "git fetch".
> Various co-workers use the remote named "central" instead of
> "upstream" and "fork" instead of "origin" (because that just makes
> more sense to them and it's perfectly valid).
>
> However if relative submodules require 'origin' to exist AND also
> represent the upstream repository (in triangle workflow), then this
> breaks on several levels.
Can you explain further? In a triangle workflow, "git fetch" will
pull from the 'origin' remote by default and will push to the remote
named in the '[remote] pushdefault' setting (see "remote.pushdefault"
in git-config(1)). So you can do
[remote]
pushDefault = whereishouldpush
and then 'git fetch' and 'git fetch --recurse-submodules' will fetch
from "origin" and 'git push' will push to the whereishouldpush remote.
It might make sense to introduce a new
[remote]
default = whereishouldfetch
setting to allow the name "origin" above to be replaced, too. Is that
what you mean?
Meanwhile it is hard to fork a project that uses relative submodule
URLs without also forking the submodules (or, conversely, to fork some
of the submodules of a project that uses absolute submodule URLs).
That's a real and serious problem but I'm not sure how it relates to
the names of remotes. My preferred fix involves teaching git to read
a refs/meta/git (or similarly named) ref when cloning a project with
submodules and let settings from .gitmodules in that ref override
.gitmodules in other branches. Is that what you were referring to?
Curious,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
