7

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)?

Community
  • 1
  • 1
Hampton Smith
  • 323
  • 2
  • 9
  • 2
    I don't believe this is a duplicate of that question. The OP over there is asking about how to skip rebasing of empty commits, whereas OP here is asking about how to allow `git rebase` to create empty commits. – Alexander Bauer May 29 '14 at 03:24
  • But why do you want an empty commit? An empty commit signifies that all the work done in it was introduced in a commit from the branch that was rebased onto. In which case, the whole commit needs to be removed. That could be done after the fact (such as by using an interactive rebase and omitting the unwanted commit) or by other methods, but it's certainly "wrong" to have an empty commit. – ErikE Nov 17 '15 at 21:33

1 Answers1

2

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.

eckes
  • 64,417
  • 29
  • 168
  • 201