Force git to make no-op commits during rebase

Question

So I've jumped through a lot of hoops to make the fork/rebase/pull-request git workflow palatable to developers on my team who fear version control and the command line.

In adding a rebase article to our development wiki, I just got to the point where I say "Do git rebase. If there are any merge conflicts, fix them. Then do a git add. Then do git rebase --continue."

But in working through the example and taking the screenshots, I was reminded that if there's a merge conflict, and I resolve it in favor of the upstream branch, doing a git rebase --continue in fact refuses to continue and gives an error:

No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.

There's an excellent discussion of the technical details here: Git rebase: conflicts keep blocking progress

But what I'd like is to make this behavior stop.

I assume there's a good design reason why this happens (probably related to rebase just using the normal commit machinery, where this behavior likely makes sense) but in this situation it's confusing and unintuitive and makes the conflict logic: "Fix the conflict. If your fix looks exactly like the upstream branch, do a git rebase --skip. In all other cases, do a git rebase --continue."

Is there a way to squelch this behavior, either with a flag to rebase or in a version-controlled configuration file (so I don't have to set it up on each dev's computer or provide instructions for doing so)?

Answer 1

The current documentation of git-rebase mentions a --keep-empty option:

--keep-empty
     Keep the commits that do not change anything from its parents in the result.

Unfortunately, there's no setting for this to put into a config file.