git remote set-url --add --push origin git@github.com:Foo/bar.git
git remote set-url --add --push origin git@gitlab.com:Foo/bar.git
:-)see: https://git-scm.com/docs/git-remote#Documentation/git-remote...
Now I'm just annoyed that more teams I've been on haven't set this up!
One serious question though: how do you deal with PRs when you do this? That's one area where it feels like things could be quite messy, especially if you have quite a few PRs going in throughout the day.
Having looked briefly into it now, git-dit does look promising in its approach. I'd be interested to hear from someone who had actually used it and bumped up against the limitations: https://github.com/neithernut/git-dit/blob/master/doc/datamo...
[1]: https://github.com/google/git-appraise
[2]: https://github.com/forgefed/forgefed
[3]: https://drewdevault.com/2018/07/23/Git-is-already-distribute...
If you have any discrepencies in between them, you'll need to merge locally of course.
I have two git repositories which somehow got into an inconsistent state: How can I reconcile changes in both repositories and resolve conflicts between mutable-metadata (branches, tags) in a sane way?
Alternatively you decide the one of the repositories is the primary one, set up a remote called `mirror` and set-up a `post-receive` hook to:
git push --mirror mirror
Now just ensure no one pushes into the mirror directly. Of course this only works if you control the primary repository.Tags: Don't have a process which can result in tags pushed into different places. It's a path to madness. Same applies to master/release branches.
Yes. This was the case I had in mind. Path to madness.
For most people, it would be just a read-only copy. And the value of that is fairly small.
[timwolla@/s/xxx (master)]g remote show origin
* remote origin
Fetch URL: git@git.example.com:xxx.git
Push URL: git@git.example.com:xxx.git
Push URL: keybase://private/timwolla/xxx
HEAD branch: master
Remote branch:
master tracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)[0]: https://cets.seas.upenn.edu/answers/git-repository.html
[1]: https://blog.osdev.org/git/2014/02/13/using-git-on-a-synolog...
[2]: https://git-scm.com/book/en/v1/Git-on-the-Server-The-Protoco...
I've used this on NFS drives, but also SMB shares from windows, and just about anything that can be mounted to a folder. Having an external hard disk drive or usb stick also works.
And lastly, git also comes with a daemon mode which makes it easy to temporarily host a server for a repo. Just connect multiple laptops trough Wi-Fi, and work together (with a pull workflow rather than a push workflow). That's quite useful [1]
[1]: https://stackoverflow.com/questions/377213/git-serve-i-would... Further reading: https://git-scm.com/book/en/v1/Git-on-the-Server
> Yes, but you can also push/pull from a filesystem location. To be able to push it, it is simpler to init the repo with `git init --bare`.
Personally, I have build my very own and simple solution to sync encrypted files over the Internet using git with git-remote that uses filesystem location. The implementation evolved over time but initial idea[0] was to combine restic, pass and git with simple scripts to pull/push the git-remote repo (located in /tmp/repos) to S3 bucket via restic that takes care of upload, deduplication and encryption. Thanks to restic I also don't care much if I'd commit to stale (outdated) master branch, because it uses snapshots and it's quite easy to navigate between them.
[0]: Year-old PoC of encrypted repository share with B2 as a storage: https://gist.github.com/piotrkubisa/dece2fc71399efa56e2d0b8f...
But why not just have different remote names other than the default of “origin”? Somebody else on the thread mentioned that it might be a bit complicated to clean things up after an outage on such a “multiplexed” remote.
> Note that the push URL and the fetch URL, even though they can be set differently, must still refer to the same place. What you pushed to the push URL should be what you would see if you immediately fetched from the fetch URL. If you are trying to fetch from one place (e.g. your upstream) and push to another (e.g. your publishing repository), use two separate remotes.
which seems to imply that weirdness might happen if the two happen to get out of sync, or if one (specifically, the one pointing to the repository you're fetching from) fails.
For something that may be a bit safer, I believe it's possible (but haven't tested) to have multiple values for branch.whatever.pushRemote-- that should do the same thing, and has the added bonus of making the secondary remote easily fetchable.
What it does affect is the ability to do code reviews, work with issues, maybe even do releases. All the non-DVCS stuff.
Pushing to all three isn't that difficult. The hard part is reconciling after one of them suffers an outage or partition.
Perhaps what they really meant is that they couldn't get to stack overflow :-(