Multiple push remotes via aliases

I recently discovered that it was possible to specify multiple push URLs for a remote. This is useful for me because some of my projects live both on GitHub and on my own server, and some live only one place or the other.

One feature that I'm looking for, however, is the ability to specify those URLs by reference to another remote. For example, making the remote def (default) refer to the remotes gh and upstream instead of duplicating the URLs. This makes dealing with URL changes easier and goes along with the DRY approach.

I don't think we already have this functionality (at least I don't see code for it), and I'd like to implement it, but maybe the documentation is just missing and I should submit a patch for that instead. Do we have such a thing, and if not, do people think this is a worthwhile feature?

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Two issues that immediately comes to my mind are

 (1) how you deal with a misconfiguration that makes a loop;

 (2) how would you disambiguate a local directory and a nickname.

I do not think either is insurmountable and as long as clean solutions for them are implemented I would say "why not?" for the new feature. Of course there may be other issues other than these two knee-jerk ones.

On Sun, May 10, 2015 at 11:46:27AM -0700, Junio C Hamano wrote:

I was certain you were going to ask this. My plan is to only allow one level of reference as a first pass and check for the current remote name. If there's a desire to extend it to multiple levels, we can implement loop checking then. A list of already-seen entries could be used in that case.

I was going to do something like this:

[remote "def"]
	reference = upstream
	reference = gh

The same rules for "def" would apply that are currently used, and "upstream" and "gh" would clearly be references, not remote URLs.

I had planned to essentially make "git push def" work like "git push upstream; git push gh", forbidding fetch and push entries at the same time as reference entries. Future work could use referenceURL to refer only to the URL and allow fetch and push to be used.

I'm also going to update the documentation to reflect that multiple push URLs can be specified, as it seems that's a well-kept secret.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/10/2015 08:17 PM, brian m. carlson wrote:

For fetching, we already have

ISTM that your feature is akin to this one and could piggyback on the same configuration. By analogy with "git remote update <group>", the corresponding command could be

    git remote push <group> [...]

You suggested being able to run something like

    git push <group> [...]

which is a little bit shorter. If so, then it is natural to ask whether <group> should be allowed in place of <repo> whenever it makes sense, as a general UI principle. If so, then

    git fetch <group> [...]

could be shorthand for "git remote update <group> [...]".

But please note that I haven't thought about whether the <repo> -> <group> generalization could be done consistently, vs. whether the groupwise commands are different enough from the single-repo commands that the supposed generalization would be more confusing than useful.

Michael

- -- 
Michael Haggerty
mhagger@alum.mit.edu

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlVQuhUACgkQwg9mrRwfmAkFbQCghrQhBaerq0W7suJzu0cr7RGW Cy0AoIkvgbWmOnwJfeldk73vNMPbc197 =arW/ -----END PGP SIGNATURE-----