Question

I want to have a blessed repository and several group or developer repositories.

Developers shall clone from the blessed repository work on that cloned repository and commit their changes. Whenever they feel like their work is completed, they shall push their changes to their public repository. Then the lead developer shall pull the changes from the public developer repository – do whatever he wants to do with it (sign off, modify, etc.) and then push it to the blessed repository.

In any environment where code reviews count code might get rejected. Assume developer A and B work on a feature at the same time. Both developers finish their work and push the patches to their public repository. The patches of developer A get accepted while the patches of developer B are rejected. Then the lead developer pushes the changes of developer A to the blessed repository. Developer B fixes the patches and rebases his work on top of the blessed repository (the accepted changes of developer A respectively). If developer B pushes his work now to his public repository he will receive an error that the
repositories have incompatible histories.

The only way I could fix that was to delete the public repository and to recreate the repository. Is there a cleaner way to fix that?

Answer 1

Considering the public repo has for only client the integration manager, B can safely force push his work:

git push --force

The integration manager hasn’t accepted any of B’s commits, so B can rewrite the history of his commits and push them again.
Would anyone else clone/pull from B’s public repo, then a push --force wouldn’t be considered an acceptable solution.

---

The OP Alex added in the comments:

So do I get that right? if anybody would pull from B the workflow is broken because the blessed repo isn’t a strict ordered subset of B’s ?

I replied:

If anybody else pulled from B’s public repo, then that history becomes public (which it is not in your scenario, since only the integration manager pulls, and don’t even keep B’s commits).
And you shouldn’t rebase public history. See Pro-Git book “the peril of rebasing” section

So if I have a hotfix to push to the blessed repo I’d kill all the stuff from my public repo to be as close as possible to the blessed one? Or how would the lead then cherry pick hotfixes?

If you have other stuff in your public repo which haven’t been accepted yet, you could publish your hotfix in a dedicated ‘hot_fix‘ branch (that B has first rebased on top of blessed repo, and then pushed to B’s public repo) , monitored by the integration manager just for that.

Anyway, the point is: that integration manager always expects new commits on top of his existing set of commits, new history, not a conflicting history (because of a lack of rebase from B).
Any conflicting history should be rejected, whatever the origin of the branch.

And beware of cherry-picking, it can lead to troubles. See:

• “In Git, how do you apply a commit of bug fix to the other newer branches?“
• “do a git cherry-pick in multiple branches“