Reputation: 2603
We are using a very simple git workflow where most active development happens on the same branch. As a result, when developers do a git pull
it usually causes a merge commit. Twice in the last week we have had novice git users do a pull that resulted in merge conflicts, and then they removed all files that they did not personally work on and committed the merge. Obviously this resulted in any changes by other developers from the commits they were merging in being removed.
How can you tell if a merge commit was modified in a way that doesn't match either parent for files without a conflict? (Essentially I want to know if there's a good way to detect a "bad" merge or not.)
Is there any systematic way to keep this from happening again?
Upvotes: 0
Views: 64
Reputation: 10876
To directly answer your question, this command
git diff-tree -r --diff-filter=D --name-only $PARENT $CHILD
will list all files that were deleted by the $CHILD
commit. If you iterate over all the parents of a merge commit and check that command, and they all show a deletion, then you will know that a file was deleted in the merge but not in any of the merge parents.
That said, this is an awfully specific solution to what sounds like a bigger problem with your developers and your source control. For a slightly better solution, consider teaching your developers to use git pull --rebase
or git fetch && git rebase
. I find merge commits hard to follow myself, and it seems like your developers do too. You could prohibit merge commits entirely, if you want.
For the best solution, have good test coverage. If your developers delete random files, it should break tests.
Upvotes: 1