From: Michael Haggerty <mhagger@alum.mit.edu>
To: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Subject: Re: Multiple push remotes via aliases
Date: Mon, 11 May 2015 16:17:58 +0200 [thread overview]
Message-ID: <5550BA16.2090304@alum.mit.edu> (raw)
In-Reply-To: <20150510181703.GC225482@vauxhall.crustytoothpaste.net>
-----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-----
prev parent reply other threads:[~2015-05-11 14:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-10 18:17 Multiple push remotes via aliases brian m. carlson
2015-05-10 18:46 ` Junio C Hamano
2015-05-10 19:10 ` brian m. carlson
2015-05-11 14:17 ` Michael Haggerty [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5550BA16.2090304@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.