Re: Relative submodule URLs

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Aug 18, 2014, 20:55 UTC
Message-ID: <20140818205505.GA20185@google.com>
In-Reply-To: <CAHd499CRNjp-UzXiTt=xgDJWGOEqew+AuPFmrF3-VsEGefXiuA@mail.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".

Show 7 quoted lines

> 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