RE: [PATCH v2 0/8] Handle pull option precedence

It's a bit tedious to keep repeating all the ways this approach is
flawed, but here we go again.

Elijah Newren via GitGitGadget wrote:

Based on a recent list of rules for flag/option precedence for git-pull[1]
from Junio (particularly focusing on rebase vs. merge vs. fast-forward),
here's an attempt to implement and document it. Given multiple recent
surprises from users about some of these behaviors[2][3]

It might have been a surprise for you, but Son Luong Ngoc's usage of the
options is correct.

 * Patches 1-2: new testcases (see the commit messages for the rules)

These test cases check for backwards incompatible changes, not what the
code is doing (and is supposed to be doing) right now.

 * Patch 3: Alex's recent patch (abort if --ff-only but can't do so)

This breaks backwards compatibility.

Users will complain.

 * Patches 4-6: fix the precedence parts Alex didn't cover

Yet another backwards incompatible change.

 * Patch 7: Alex's other patch, abort if rebase vs. merge not specified

More brekage without a single day of deprecation warning.

 * Patch 8: Compatibility of git-pull with merge-options.txt (think
   rebasing)

This doesn't update anything in Documentation/config, which is now
clearly broken.

-- 
Felipe Contreras