Multiple push remotes via aliases

Multiple push remotes via aliases

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

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 / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Multiple push remotes via aliases

[Junio C Hamano]

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

> 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.

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.

Re: Multiple push remotes via aliases

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

On Sun, May 10, 2015 at 11:46:27AM -0700, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > 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.
> 
> Two issues that immediately comes to my mind are
> 
>  (1) how you deal with a misconfiguration that makes a loop;

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.

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

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.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Multiple push remotes via aliases

[Michael Haggerty]

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

On 05/10/2015 08:17 PM, brian m. carlson wrote:
> 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?

For fetching, we already have

> remotes.<group> The list of remotes which are fetched by "git
> remote update <group>". See git-remote(1).

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-----