So, I jumped over a lot of hoops to make the fork / rebase / pull-request git workflow acceptable to my team developers who are afraid of version control and command line.
When I added the redirect article to our development wiki, I just got to the point where I say "Do git rebase . If there are merge conflicts, fix them, then do git add . Then do git rebase --continue ."
But while working on the example and taking screenshots, I was reminded that if there is a merge conflict, and I resolve it in favor of the upstream branch, then git rebase --continue actually 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.
Here's a great discussion of technical details here: Git rebase: conflicts keep blocking progress
But I would like to stop this behavior.
I suppose there is a good reason in the design why this happens (probably due to the permutation only using the usual commit mechanism, where this behavior probably makes sense), but in this situation it is confusing and unintuitive and makes the logic of the conflict: " Fix the conflict If your fix looks exactly like an upstream branch, run git rebase --skip . In all other cases, run git rebase --continue . "
Is there a way to suppress this behavior, either with a flag for redirection, or in a configuration file with a controlled version (so I do not need to configure it on every dev-computer or give instructions for this)?
Hampton smith
source share