Hacker News Reader

Comment by bluejellybean | Hacker News Reader

Hah, today I learned! It's a great feeling when you don't have to reinvent a wheel, thanks.

Now I'm just annoyed that more teams I've been on haven't set this up!

Now that you solved your problem. Let me guess your next question:

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?

Tags are going to be ugly, but branches can simply be merged like any other.

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.

Wasn't the original point to be able to push to the second copy when the first is down .. what's the point (other than backup) of a second "working" copy that you can't use.

A repo admin or script could enable pushing permissions to the mirror while the primary is down. The when the primary is back up, fast-forward it and change back. Or, just allowing pulling from it and wait to merge until the primary is fixed.

Branches: Let each branch owner deal with that. They likely have the most information about it. Create a new temporary branch, merge both sides into it and see what happens.

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.

> Same applies to master/release branches.

Yes. This was the case I had in mind. Path to madness.

You can just push and pull directly to/from your colleague's computers. The main advantage (for an established team) of github/gitlab/bitbucket are pull requests, issue management, CI etc., and that's not easily synchronized across multiple providers.

Me too. That's awesome: I've just suggested it to our team. Thanks for sharing GP!

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.

Pull requests could be done through email using the git format-patch, git send-email, and git am commands.

You could merge the feature branch into master (or whatever), resolve conflicts, commit, push and deploy.

There have been various proposals over the years for how to integrate issues and reviews in the distributed git tree itself (http://dist-bugs.branchable.com/software/), but I don't think any of them have really gone anywhere, certainly not in terms of support by the hosted git vendors.

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...

There is git-appraise to fill that gap [1]. I am personally waiting for a federated "forge" for federating PRs across platforms, such as the one developed in [2]. Maybe via e-mail? [3].

[1]: https://github.com/google/git-appraise

[2]: https://github.com/forgefed/forgefed

[3]: https://drewdevault.com/2018/07/23/Git-is-already-distribute...

Merge the PR on github, pull to your local copy (now you're ahead of one of the urls of origin), push (and it should just push to the origin that's behind)

If you have any discrepencies in between them, you'll need to merge locally of course.

> Now I'm just annoyed that more teams I've been on haven't set this up!

For most people, it would be just a read-only copy. And the value of that is fairly small.

Reply on news.ycombinator.com