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

Our team uses a purely merge-based git workflow, and we're discussing the possibility of just asking all team members to push all work to server one afternoon and do an evening of rebasing the server repo.

I (think) what I would like to do automatically is that as long as all the commits are only on the same set of branches AND the number of par开发者_开发百科allel commits are below a given threshold I would like to rebase the series and remove the merge commit(s). But I am open to suggestions ?

Anyone know how to do this ?

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.

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 (e.g. git pull -r)? 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.