So I tend to have a recent clone of a repo I need to work on "very close" network wise (frequently on the local disk). There is also an "official" server that my workflow really wants to be the origin, but it is frequently very slow (either because it is overloaded, or on a distant network, or both).
(this local repo is a clone of the official server, tending to be a week or two out of date, but the repo is very large and has about a decade of history imported from older VCSes, so the local clone plus fetch from remote is a lot faster)
If I git clone -o local /path/to/repo
and then git remote add -f origin URI-for-offical-repo
will I end up with the same thing(*) git clone URI-for-offical-repo
would have given me?
I'm especially wary of any subtle differences that might make a push from my repo different. Also if I start using this method of accelerating the clone the "local" repo may have been made using this method, maybe for multiple generations.
(*) the same plus the extra remote name "local", and anything that hadn't been pushed from local to the official server.
Short answer: Yes, probably.
Long answer: The "origin" is simply an alias for where you'd usually want to push. As long as the new destination is related to the repository you've pulled from (or an empty repository), and you have write access to it, it should be safe.
NOTE: I've not really considered that your "pseudo code" command example is sensible. But the concept of cloning then changing the url for the "origin" is a sensible concept. I've done it myself when server addresses have moved, or I've decided to change my public repo location, etc.
Beware though, if the new origin is NOT a completely empty repository, or an old clone of your local repo (with no newer commits than on your local one), using
git push --mirror #e.g. implicitly to "origin"
can overwrite, and discard branches on the remote if you have full write access to it. (This I've also managed to do myself, when carelessly copy and pasting .git/config data from one repo to an unrelated repo. [Fortunately it had plenty of up to date clones; but I was sweating for some seconds when delete messages scrolled all over my screen ;) ])
What you are doing looks to be fine but you might be looking for the --reference
option that was added to git clone some time ago. If there is a local copy this makes it very quick to create a new clone using the reference repository packs and then just updating from the network. eg: git clone --reference ./oldercopy $url newcopy
For your current scheme - provided the tree's are related there is no problem switching url's for the remotes. If they are unrelated, then all manner of unpleasant error messages will show up.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With