4

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.

distribued workflow

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?

Alexander Oh
  • 24,223
  • 14
  • 73
  • 76
  • Saturday evening, (or Monday morning for Greg?) and a question about 'git' still gets answered. --3 times-- (now 2). By some of the usual suspects... :) – VonC Sep 18 '11 at 21:35
  • @VonC: indeed, I wouldn't have spent so long deciding on whether to use his / her / their for the integration manager if I'd realized there would be three replies within 30 seconds of each other :) – Mark Longair Sep 18 '11 at 22:21

2 Answers2

2

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:

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 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 ? – Alexander Oh Sep 18 '11 at 21:42
  • @Alex: 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: http://progit.org/book/ch3-6.html#the_perils_of_rebasing – VonC Sep 18 '11 at 21:44
  • 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? – Alexander Oh Sep 18 '11 at 22:02
  • @Alex: If you have other stuff in your public repo which haven't been accepted yet, you could publish your hot_fix 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. – VonC Sep 18 '11 at 22:12
  • @Alex: and beware of cherry-picking, it can lead to troubles: http://stackoverflow.com/questions/3312254/in-git-how-do-you-apply-a-commit-of-bug-fix-to-the-other-newer-branches/3312341#3312341 or http://stackoverflow.com/questions/3476829/do-a-git-cherry-pick-in-multiple-branches/3476881#3476881 – VonC Sep 18 '11 at 22:13
1

You can arbitrarily change the history in a public repository by using push -f to force update the remote. Since the individual developer is the only one who should be changing their own public repository, this is normally a safe thing to do.

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285