On 7/16/21 9:14 PM, Felipe Contreras wrote:
Elijah Newren wrote:
It may be a worthy goal, but I cannot implement correct behavior if I
cannot determine what correct behavior is.
You've only specified how to handle a subset of the valid combinations
in each of your emails, and from those individually or even
collectively I cannot deduce rules for handling the others. Reading
the dozen+ recent messages in the various recent threads, I think I've
figured out your opinion in all but two cases, but I have no idea your
intent on those two (I would have thought --rebase override there too,
but you excluded that), and I'm rather uncertain I've correctly
understood you for the other ones (I really hope gmail doesn't
whitespace damage the following table):
pull.ff pull.rebase commandline action
* * --ff-only --rebase fast-forward only[1]
* * --rebase --no-ff rebase[1]
* * --rebase --ff rebase[1]
* * --ff-only --no-rebase fast-forward only
* * --no-rebase --no-ff merge --no-ff
* * --no-rebase --ff merge --ff
<unset> * --no-rebase merge --ff
only * --no-rebase merge --ff[2]
false * --no-rebase merge --no-ff
true * --no-rebase merge --ff
<unset> * --rebase rebase
only * --rebase rebase[2]
false * --rebase ?[2]
true * --rebase ?[2]
* * --ff-only fast-forward only[1]
* <unset> --no-ff merge --no-ff
* false --no-ff merge --no-ff
* !false --no-ff rebase (ignore --no-ff)[2][3]
* <unset> --ff merge --ff
* false --ff merge --ff
* !false --ff rebase (ignore --ff)[2][3]
What about
* !false --ff-only ???
I think these are conflicting options, see [ ] (the ref without a
number). This feels like saying oh, I want to rebase, but I want to
fast-forward. What should happen with my local changes then? Could one
argue that this should lead to the local changes being rebased on top of
the remote?
[1] https://lore.kernel.org/git/xmqq7dhrtrc2.fsf@gitster.g/
https://lore.kernel.org/git/c62933fb-96b2-99f5-7169-372f486f6e39@xxxxxxxxxx/
[2] https://lore.kernel.org/git/xmqqpmvn5ukj.fsf@gitster.g/
[3] https://lore.kernel.org/git/xmqq8s2b489p.fsf@gitster.g/
It appears you, Phillip, and I all had different opinions about
correct behavior and in a few cases though the documentation clearly
implied what we thought. So, I'd have to say the documentation is
rather unclear as well. However, even if the above table is filled
out, it may be complicated enough that I'm at a bit of a loss about
how to update the documentation to explain it short of including the
table in the documentation.
Yeah, now you are starting to see the problem.
How many more failed attempts do you need to go through before accepting
that the approach you thought was feasible is in fact not feasible?
The solution is simple and self-documenting:
pull.mode={fast-forward,merge,rebase}
--
aixigo AG
Karl-Friedrich-Str. 68, 52072 Aachen, Germany
phone: +49 (0)241 559709-390, fax: +49 (0)241 559709-99
email: matthias.baumgarten@xxxxxxxxxx
web: https://www.aixigo.com
District Court Aachen – HRB 8057
Board: Christian Friedrich, Tobias Haustein
Chairman of the Supervisory Board: Dr. Roland Schlager
