0

Our team currently ran into a few issues where developers accidentally rolled back history on certain files. To be specific, someone ran into merge conflicts and clicked on revert in tortoisegit and rolled back a bunch of files.

We already have a few git pre push hooks, so wanted to check if there is any way that we could check that history is being rolled back and thereby prevent a push

here are 2 scenarios in the recent past that I can give as example

  1. A developer had merge conflicts on 50 files . He clicked on revert in tortoise git and it rolled back the 50 files to an earlier version. This was however a rollback of only those 50 files. The other files were not affected.

  2. A developer was merging a master branch into his branch. When presented with merge conflicts, he simply selected the option that his files will always be preferred over files in master for around 100 files. As a result he rolled back the history of 100 files

Also, we have multiple repos in our team and all of them share pre-push hooks . It would be less time consuming for me to implement it as a pre push hook than to add this option in the bare directories for all the repos

Biswajit_86
  • 3,661
  • 2
  • 22
  • 36
  • possible duplicate of [How do you detect an evil merge in git?](http://stackoverflow.com/questions/27683077/how-do-you-detect-an-evil-merge-in-git) – jthill Mar 08 '15 at 01:01
  • I don't understand the issue. Why can't the developer just `git reset` to the commit before the merge and try again? – Sukima Mar 08 '15 at 01:37
  • The problem is that the issues were not obvious to the developers. It took some time figure out that the history had been messed up. After we did a git reset, everyone who had committed code after the debacle had to recommit and that was a serious waste of time – Biswajit_86 Mar 08 '15 at 01:42

1 Answers1

2

In git, "revert" and "reset" are two separate operations, and only git reset actually rolls back history.

If someone uses git reset to roll back the history of their local repository, setting the following parameters in the configuration of the remote repository will prevent them from pushing their changes:

receive.denyNonFastForwards = true
receive.denyDeletes = true

If someone actually runs git revert, you can't really protect against that: a revert operation generates a new commit that reverses the changes made in a previous commit. This is a normal part of development, and from git's perspective is really indistinguishable from someone making the same changes manually and committing them.

This question suggests how to detect forced updates in a way that may be amendable to a pre-push hook if you want to check this in a local repository.

Community
  • 1
  • 1
larsks
  • 277,717
  • 41
  • 399
  • 399
  • 1
    Yawar: If you have a comment to make please make a comment rather than adding text to my answer. Thanks! – larsks Mar 08 '15 at 01:17
  • is there a way to check this in a pre push hook – Biswajit_86 Mar 08 '15 at 01:19
  • 1
    I don't know, but the problem with a `pre-push` hook is that it has to be configured for everybody, all of the time, and if someone forgets to set up the hook they can still push their changes to the remote repository. This sort of thing is much better to configure on the server side, because this no longer depends on individual developers to maintain the expected hook configuration. – larsks Mar 08 '15 at 01:22
  • We have pre push hooks on server side as well as client side. – Biswajit_86 Mar 08 '15 at 01:23
  • [This question](http://stackoverflow.com/questions/10319110/how-to-detect-a-forced-update) suggests how to detect a forced push in a way that may be useful in a `pre-push` hook. – larsks Mar 08 '15 at 01:24
  • can you please add the link that you pasted in your comment and i will accept your asnwer – Biswajit_86 Mar 08 '15 at 01:44