26

I accidently overwrote another developper's changes when doing a merge in git. I know how to undo the last commit, that is, my merge.

My problem is that I already pushed those commits into our online repository. So if I roll back, do my merge merge again (with his modifications this time) and try to push it again, there will be a conflict (right?). What is right the way to handle this ?

EDIT To clarify, here is what the situation looks like :

commit A --- commit B --- merge

But in the merge I accidentally discarded the modifications made in commit A. This isn't really a problem. I know how to make the changes locally (undo the merge). But my problem is that the whole thing has been pushed into our shared repository (think github or bitbucket).

nha
  • 17,623
  • 13
  • 87
  • 133
  • 1
    Observe that "change a revision" is really "delete a revision and add a new, different revision". – Jean-Paul Calderone May 23 '14 at 15:14
  • 2
    This doesn't seem like a duplicate of the suggested question. The suggestion covers rolling back a local change, but the OP here is asking about rolling a remote repository back to a previous state. – Caleb May 23 '14 at 15:22
  • @Caleb thank you, that's exactly that. I made an edit to try to explain further, but that's the idea. I should have added, I'm a git noob. – nha May 23 '14 at 15:24
  • 2
    I think the cleanest solution would be to re-apply the commit A patch with `git cherry-pick`. This way you would _add_ to the history rather than changing it, which is always a bad idea if the history is published! – musicmatze May 23 '14 at 15:25
  • @musicmatze I see. so `git cherry-pick `, right ? And the ownership of the commit will be preserved also, is it correct ? I don't want to claim it as mine... – nha May 23 '14 at 15:26
  • 1
    @nha Yes, the ownership will be preserved. – Aaron Brager May 23 '14 at 15:28
  • 1
    as @poke mentioned in his answer, you can `git revert` merges, too. So maybe this is another option! – musicmatze May 23 '14 at 15:29
  • I should add that I don't think this is a duplicate. This is sometimes close, but some "duplicates" don't present the problem of a remote repository. Some others don't consider the same scenario (ie add/replay a commit instead of deleting one). This yields different solutions, like the git `cherry-pick`. – nha May 24 '14 at 14:45

1 Answers1

9

By default, remote servers will disallow overwriting already pushed commits. This is because those new commits are different objects which are incompatible to those published before. This means that anyone who has already fetched from the remote since will have major problems fixing it once you overwrite the commit. So you should really reconsider overwriting the commit with something else. Note that git revert works with merge commits too, so you might want to consider that instead.

That being said, you still can push that rewritten commit even if it conflicts with what’s on the server. You can do that by force pushing using git push --force or git push -f in short.

poke
  • 369,085
  • 72
  • 557
  • 602
  • I'm not sure I understand `git revert`. Will I be able to push to the repository, and nothing happened ? Or does it add a commit that is the exact opposite of the last ? Do you happen to have an opinion about `git revert` vs `git cherry-pick` ? – nha May 23 '14 at 15:34
  • Yes, `git revert` will add a new commit that undoes the selected commits. So pushing it will work since it won’t *remove* any already published commit. – poke May 23 '14 at 15:36
  • thank you ! I'll accept your answer, but I upvoted you as well @musicmatze . (I'd be happy to hear an opnion about the respective merits of both options) – nha May 23 '14 at 15:40