Automatically rewrite full git history to get rid of simple merge commits

Answer 1

I'm not sure how simple this could be. If you do a rebase -i, it will attempt to ignore all merges, which succeeds for merges without conflict, but stops and waits for you if there was a conflict.

If you invoke it as rebase -i -p, on the other hand, it will preserve merges, which is what you want when the user did a real merge, but completely misses the point otherwise.

Perhaps some sequence of the two commands, preserving merges only when you want to, could get the job done in this case.

I must agree with Charles, though, that having the history reflect reality is much more valuable than making it "look pretty". The fact is, one commit was made without knowledge of the other, and in the case of source code this can tell you why something might have gone wrong.

Our team uses a purely merge-based git workflow

What's wrong with always pulling with --rebase? If you desire a flat topology, the simplest way is not to merge when you could rebase.

Also: you say you only want to flatten if "the merge is clean". I'm just speculating here, but I don't think git records conflicts after the fact other than a note in the default commit message, which may not still be there.

Answer 2

In my opinion you should avoid the temptation to re-write history just to make it "look nice". There really is no point. The history, as it is, is a more accurate representation of reality and git's reporting tools are all designed to be useful even with lots of little merges.

If you're not interested in viewing a lot of merges you can suppress them from many reporting tasks, e.g.

git log --no-merges

What you're proposing (an evening of rebasing, presumably causing all developers to have to reset) seems like creating work for work's sake.