Set up your git remotes (‘origin’ and ‘foo’)
Create a new remote (‘all’) entry to encompass the existing targets
Adjust ssh config as needed
git push all HEAD
CommentsSubscribe to the comments RSS feed.
Comment #1 posted on 2016-10-02T14:12:28Z by clacke
I figured :-)
I thought, "Hey, this is probably useful if you want to host something at gitlab and have an unofficial clone at ". One minute later ... yep. :-)
Comment #2 posted on 2016-10-02T16:11:54Z by clacke
Very cool discovery! I never even considered the idea that you could have several URLs for a remote.
As you mentioned that this kind of mixed remote would make it "impossible" (without adding remotes) to push to only one of the URLs, I though I should mention something that probably not everyone knows:
You don't need to set up a remote to fetch or push. You can use an explicit URL instead of a remote name:
git push ssh://my.server/~/git/myrepo HEAD:master
In fact, because I forget what the various options are for managing references/branches, I often use this to remove a reference in the local repository.
git push . :refs/heads/whatever_branch
Comment #3 posted on 2016-10-08T09:17:18Z by klaatu
Funny you mention the explicit push. I knew about it, or at least I knew about the explicit pull, because I use it when migrating git repositories at work...but only with local URI's. It never dawned on me that it could be done with non-local URI's. Thanks for the tip!
Comment #4 posted on 2016-11-02T12:20:52Z by Dave Morriss
Thought I'd never use this
This was interesting, but I thought I'd never use it. However, I had an instance recently where making a GitHub copy of a repository on a GitLab instance was desirable. It was straightforward to set up and worked flawlessly.
Thanks for explaining the process.