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
