Junio C Hamano wrote: > Elijah Newren <newren@xxxxxxxxx> writes: > > > <unset> * --no-rebase merge --ff > > only * --no-rebase merge --ff[2] > > false * --no-rebase merge --no-ff > > true * --no-rebase merge --ff > > I think the second one deserves an explanation. The rationale for > ignoring --ff-only is because the act of giving an explicit > "--rebase" or "--no-rebase" from the command line, when the > configured default is "I expect to have no development on my own > here, and only want to follow along", is a sign enough that the user > does not want to follow along in this particular invocation of > "pull". And the rationale for the entire thing to become --ff is > only because between --ff and --no-ff, the former is the default. > > About the second one, I would understand it if it became "merge > --ff-only", too. That is more trivially explained. I however > suspect that it would be less useful, but that is open to > discussion. It would be very hard to explain in the documentation why these are different: git -c pull.ff=only pull --merge git pull --ff-only --merge And this of course will break behavior for people that arely already relying on pull.ff=only to do --ff-only (as it was its whole purpose). Not to mention that this isn't even listed in the table: git -c pull.ff=only pull As well as *all* the configurations with no command line arguments. -- Felipe Contreras
