Re: Relative submodule URLs

[Jonathan Nieder <jrnieder@gmail.com>]

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