"D. Ben Knoble" <ben.knoble+github@xxxxxxxxx> writes: > When running "git pull" with the following configuration options, we > fail to merge divergent branches: > > - pull.ff=only > - pull.rebase (unset) > - branch.<current_branch>.rebase=true > > Yet it seems that the user intended to make rebase the default for the > current branch while using --ff-only for non-rebase pulls. Since this > case appears uncovered by existing tests, changing the behavior here > might be safe: it makes what was an error into a successful rebase. Hmph, to me it looks more like with pull.ff, the user, no matter what other variables say and which mode between merge and rebase a pull consolidates the histories, wanted to make sure they will never accept anything other than fast-forwarding of the history, because the end-user expects that they will pull only after they push out everything, i.e., the expectation is that the other side is a strict fast-forward or the user wants to examine the situation before making further damage to the local history. With that understanding, I am not sure "even though pull.ff tells us to stop unless the other side is a descendant of our history, if we are rebasing, it is OK if they have something we have never seen" is a good thing to do. So, I dunno.
