nerdherd
nerdherd

Reputation: 2603

How can you prevent or detect a merge that changes non-conflict files in git?

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

Answers (1)

Jack O'Connor
Jack O'Connor

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

Related Questions