Episode: 2130
Title: HPR2130: Git push to two repositories at once
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2130/hpr2130.mp3
Transcribed: 2025-10-18 14:40:23

---

This is HPR episode 2,130 entitled Get Pushter 2 Repositories at once.
It is hosted by Klaatu and is about 24 minutes long.
The summer is.
Klaatu demonstrates how to perform one Get Pushter 2 separate repositories.
This episode of HPR is brought to you by AnanasThost.com.
Get 15% discount on all shared hosting with the offer code HPR15.
That's HPR15.
Better web hosting that's honest and fair at AnanasThost.com.
You're listening to HPR15.com, my name is Klaatu and on this episode I want to talk about
Get Pushter 2 separate repositories at the same time.
This is a little bit of a niche issue I guess and specifically for me I only have had
to deal with it because some people out there wanted access to some of my code but they
couldn't be bothered to go to get lab to go get it.
Most of my public get repositories that I host publicly are located on get lab.
They used to be located on getorious but getorious.org went away sort of dissolved it just kind of
evaporated and as part of their sort of parting farewell they told everyone hey you should
go to getlab.com and put your stuff there instead.
This getlab.com had built a little importer where you just put in your getorious.org URL
and click a button and it just imports everything for you.
That was just kind of like the obvious and easy route so I went to getlab.com.
In addition getlab.com was the only sort of major sort of public kind of obvious choice
that was open source from top to bottom.
Getlab has a non open source version.
They're one of those sort of open core companies or whatever where they most of what they
offer is open source in the community edition and then there's like the paid for edition
where they give you a couple of fancier features and I think most of their fancy features
specifically are for continuous integration.
I could be wrong.
That might have even made it into the community edition at this point but it's not really
that big of a deal and I'm not sure how well that's even working for them.
I mean not that they're not doing well.
They seem to be doing quite well and in fact I use getlab extensively at a job.
That's kind of how I got used to their interface and the whole concept of doing get through
a web interface which is annoying but it is something that a lot of people do seem
to like for whatever reason.
They seem to be doing well and in a funny story at one job that I had they were actually
trying to pay getlab for something that wasn't on sort of the price list that the sales
people at getlab had on their computer screen and they literally turned down thousands
of dollars because they were like we don't have that you know that's not that's not
on the menu and then so we ended up using the open source the community edition of getlab
because they wouldn't take our money it was really bizarre one of those sort of eternal
questions of how you connect with people who need to get rid of some money with people
who claim to want the money you know it's like sometimes the weirdest thing that's kind
of like standing the way I mean sure sometimes you just don't know they exist or sometimes
it would take too much to to connect those two dots but in other cases it's just like
this McDonald's employee can't find the right button on their cash register and so I
can't give my money to this place and it's just bizarre that that happens and I wonder
how much that affects businesses in real life because certainly like with getlab that
was a real thing that I witnessed myself I wonder if that happens elsewhere I mean
sometimes I think people don't know that that there's an option like I don't know I wonder
how many people would pay 60 bucks for Red Hat Enterprise Linux for instance if they knew
that there was a $60 option available like I don't know but certainly when I discovered
that there was a $60 option which was like quote self support but you know you get access
to the Red Hat network and to their to their online support and stuff like that so it's a license
so if you have to have a license because of your boss or because of whatever then you can get one
for 60 bucks but a lot of people don't even know that's an option and they're like oh Red Hat's
like $800 it's kind of interesting so it's a weird problem to have and none of it has anything
to do with get I'm sorry I got distracted so anyway get get get lab yeah it was open source it was
kind of the obvious choice to go to from Gatorius so I did that and when I say obvious choice I mean
it's the it's the obvious choice that is not self-hosting self-hosting was the obvious choice but
but I do want the code to sort of be able to be found so I'm trying to leverage a public
server and get lab was just it was more open than get hub so that's kind of why I defaulted to it
now get hubs big advantage their their primary sort of the thing that they really truly deliver
is in the form of like if you go to any given get hub repository you'll see that in the right hand
corner of of the repository page there's a green button that says download or clone and that is
there that's their big that's their killer feature apparently because people go to your get hub
page looking for code or whatever and they see the big green button that says clone or download
and believe it or not that's like that's a big deal now admittedly I get lab their download
button is is puzzlingly obscured I mean it's not it's not super hard to find but like when you go
there especially if you are used to seeing a get hub repository interface when you go there like
when you look for the download button it's it's it's actually pretty hard to find it's not labeled
with text it's just an icon and the icon is white on white and it's kind of it is in the right
place like upper right hand corner sort of I mean like that that I guess it is sort of a logical
place but it's it's it's next to other buttons that you don't know what they mean and yeah it's
it's harder to find so not really sure why they do it that way but people really love this um
this green button that get hub has and so when people have asked to um to get code and I've
directed them to get lab they seem to get really turned off by that they're like get lab oh no not
get lab that's for you know that's for the geeks or people who know get I guess it's just like
really it's not that hard but yeah so um what happens is that sometimes I will take a
repository that is hosted primarily on get lab and then mirror it on get hub so that people can
can still find the code on get hub isn't that nice of me um in in practice what that meant
for a while was that I was get pushing to two separate places so get push origin head and then
get push get hub head and origin would would resolve to get lab because that's kind of like the
default label for for your initial or your initial repository um and then get hub would be the one
that I made manually to push to and that was working and it kind of kept them separate and
and and it was a two step process and it was okay it wasn't it wasn't necessarily perfect
so I I started to think well how can I make this all just sort of happen at once because it is a
mirror so I don't want to have to think about it I just want to be able to get push to my primary
repository and then have everything ripple through to the the the mirror network as it were
the way that it eventually or that that it initially came to me was to do it with a get hook
so get hooks or scripts that you can write and kind of manage um usually locally uh in in each
repository and and it's just it's an auto run script you know so it detects when you do some
some action like a commit or a push and then it does some action based on what you've done so
there's a there might be a pre commit a post commit uh post push things like that so I figured
well I could write a get hook to detect when I've pushed something and then once that push is
complete it can then kick off a script to push the same thing to my get hub repository my get hub
mirror and that was kind of an idea but I did a little bit more research and it turns out that it
it doesn't even have to be that difficult it can be it can be even simpler and that is you can just
add another push destination to your get config that seems obvious and in fact that is already
what I did but what you can do is is take your existing origin destination and add another
destination to it now I'm not saying to do this because this is actually not what I what I chose to
do there's a there's a variation on this that I that I think is a little bit better but um
but I mean you could do it you can do a for instance to so if you do a get remote dash v in your
in a get repository you'll you'll see the the remote locations of of your kind of um you know
your decentralized get network and by default typically you're going to see like if you're just kind
of like Joe user and you're just kind of doing the default get stuff then you're going to see
two entries you're going both of them are going to get the label origin and there'll be something
like let's say get at get lab.com blah blah blah fetch and origin get at get lab.com blah blah push
so the fetch one is obviously where you're pulling your your updates from and the push is the
place where you're pushing your changes to they are very frequently the same address because you're
working on the same you know from the same sort of origin point although they're not necessarily
always the same and you can add to these though you don't only have to have two entries so the way
that you would add and again I'm not saying to do this I'm just saying that this is what you could do
you can do a get remote set dash URL dash dash add dash dash push origin get at get hub.com blah blah
so what that does is it's saying I want you to take you know I want you to execute a get remote
command so get remote and then we the the sub command that we're doing is a set dash URL
and we're specifying this as an add we'll an add action we're not removing we're adding so dash
dash add and then we're specifying this as a push destination a push destination rather than like a
fetch point so dash dash push and then we're labeling it as a member of the origin group so that's
why we're doing get remote set dash URL dash dash add dash dash push origin and then the the
the location of our server get at get hub.com blah blah blah and then when you do a get push
origin head you are no longer just pushing to your get lab repository you are also pushing to your
get hub repository now there are two caveats about this I'll save the second caveat for later
because it's pretty universal but one thing to be aware of is that this obviously lumps everything
into the same group so if you would ever see an occasion where you would want to push to one and
not the other this would make it well essentially impossible you'd have to remove you have to remove
one of them in order to push you know so you what I'm saying is that this does not keep it
very modular this is now creating you know this is sort of cramming two different things into one
group and treating them basically as the same which might be what you want to do it just doesn't
feel right to me it feels like I'm taking two separate places and sticking the same label on them
just for convenience so there's another way to do this a better way to do this and that is to create
a new group entirely so the first thing that you would want to do is create a new group
so as I say the default group location is origin if that's what it's called it's not
that's not a magic word or anything that just happens to be the thing that the get programmers
the get devs chose you know as your default string when you're creating a repository the place
where you're pushing to and fetching from gets labeled origin a lot of us tend to forget that
that's just a generic name you we could rename that we could call it anything we could call it
food we could call it penguin doesn't really matter it gets called origin as a default
what for for clarity I think I would probably add a new group first called like get hub
and you would do that the same way as as you do you know what we just did like well not
exactly the same so it would be get remote and then you'd say add get hub and then get at get hub
com slot colon blah blah blah and that would create the group and instantiate that groups
sort of URL destination as the get hub address so now if you do a get remote dash v you'll see
that there's an origin entry and the get hub entry so now you've got two places and that's what
I've been flying with for a long time where I would do a get push origin head wait for that to
complete and then get push get hub head and then wait for that to complete to two step process
but at least you've got two separate locations and they're distinct and they're kind of self-standing
and that works here's how to make that better make a third group that will then encompass both
so you do a get remote add all get at get lab dot com blah blah blah so that instantiate to the
group with your default sort of get lab address and it labels it all and then you need to add
both addresses as your push destination so get remote set dash URL dash dash add dash dash push
all get at get lab dot com colon slash blah blah blah and then get remote set URL set dash URL
dash dash add dash dash push all get at get hub dot com blah blah blah so now if you do a get
remote dash v you should see that you've got three entries or three blocks I should say you
should have your origin block your which is just your get lab your get hub block which is just
your get hub and then you're all block which happens to have both your get hub and your get lab
addresses as it's push destination so now if you do a get push all head then you're pushing your
changes to both your get lab repository and your get hub repository all in one go but you maintain
the sort of distinction between origin and get hub and whatever else so that's that's my
preferred method I think it's the cleaner method you know it's it's the more sort of self documenting
method you kind of see what's going on and and I think it's also more appropriate I mean
it's not but I feel like it is because I I don't see the logic I guess in having two push entries
in in your sort of origin even though there's nothing special about origin and technically speaking
you certainly can't have to push destinations it doesn't really matter I just happen to find that
this is a little bit cleaner now the big universal caveat to all of this is that if you're using
SSH config to manage your or to help you manage your SSH keys for access into your get repositories
then this method could could fail because of that so I did an episode with on hacker public radio
about ssa dot ssh slash config it's a config file that you can have in your dot ssh file
and you can select you know you can define certain defaults on a per host level so you can list a host
like by name you know like get get hub and then whenever you push to get hub you could say well
set the well get hub is a bad example so let's say Foo so whenever you push to Foo set the port
to to to to to instead of to to set the identity file to dot ssh well to till the slash dot ssh slash
Foo underscore or id underscore Foo dot pub or not pub just id underscore Foo
um and set the username to uh not clat to instead of clat to something like that and you can do
that per host it's a very simple config file it it it's changed my life I I use it for everything
and I use it including uh get hub and get lab and I have different ssh keys on get hub as I do
on get lab so when I tried this method where I was pushing to both get hub and get lab all in one go
I kind of assumed that since they necessarily had to be two separate ssh commands running I assumed
that my ssh config file would be parsed twice but apparently get doesn't do that because the second
push kept failing I couldn't get you know like get lab would would succeed and then get hub would
fail and the only thing that I could figure out was that my ssh config was not getting looked that
twice and what was happening was that the first one that was getting pushed and I don't know
how it's deciding that I don't know if it's doing it in the order that I provided or if it's
alphabetical let's just arbitrarily say it was get lab so the first one that was being
pushed succeeded and then the second one was failing because of ssh validation so what I ended up
having to do was create a third ssh key or I chose to create a third ssh key and I set the ssh key
for both get lab and get hub and used that identity file as my authentication so that when I did a
get push I was using you know whether it was going to get hub or get lab it was essentially
it was using the same ssh key and it was getting in under under either condition I don't know if that's
like I don't know if that's my design I don't know if it's just an oversight maybe it's just
something that I'm not thinking of that I screwed up in my config in the first place I'm not sure
but it does it's something to be aware of like if you try this and it's not working
it just it might be because of ssh config now if you're not pushing via ssh then obviously that
doesn't even that doesn't that's not going to matter one way together more more more often than not
you're pushing via ssh like let's just let's be honest you're probably pushing via ssh I mean
even internally at at work I push to the local get servers via ssh you know it's just like
yes there are other protocols that can that can write to get but no one uses it so you're probably
using ssh and if you are you do have to just kind of keep in mind that that your ssh key
may not apply to one repository or you know you might be using different keys for each repository
whatever keep that in mind and if if when you try this it fails take a look at what ssh key you're
attempting to use for each login and sort it out that way because get like I say if you're using
get with the at symbol in your url you're you're using ssh so anything that it's doing is subject
to a dot ssh config parse at least once apparently not twice so that's something to be aware of
and to leverage because it it's actually useful but you just have to know that it's that it's happening
yeah that's I think that's it for me hopefully that helped it's it's probably not something that
you'll use every day but certainly if you if you feel the need to mirror a get repository and you
want it to be fairly invisible to you this is a great way to do it thanks for listening
you've been listening to hecka public radio at hecka public radio dot org we are a community podcast
network that releases shows every weekday Monday through Friday today's show like all our shows
was contributed by an hbr listener like yourself if you ever thought of recording a podcast and click
on our contributing to find out how easy it really is hecka public radio was founded by the digital
dot pound and the infonomican computer club and it's part of the binary revolution at binrev.com
if you have comments on today's show please email the host directly leave a comment on the website
or record a follow-up episode yourself unless otherwise stated today's show is released on the
creative comments, attribution, share a like, 3.0 lives in