On 9/2/23 19:37, Junio C Hamano wrote:
Wesley Schwengle <wesleys@xxxxxxxxxxxxxxx> writes:
Thanks for the feedback. I won't continue the patch series because some
of the feedback you've given below.
However doing so would trigger a different
kind of behavior. `git rebase <upstream>' behaves as if
`--no-fork-point' was supplied and without it behaves as if
`--fork-point' was supplied. This behavior can result in a loss of
commits and can surprise users.
No, what is causing the loss in this particular case is allowing to
use the fork-point heuristics. If you do not want it, you can
either explicitly give --no-fork-point or <upstream> (or both if you
feel that you need to absolutely be clear). Or you can set the
configuration to "false" to disable this "auto" behaviour.
Isn't that what I'm saying? At least I'm trying to say what you are saying.
By the way, while I do agree with the need to make users _aware_ of
the "auto" behaviour [*1*], I am not yet convinced that there is a
need to change the default in the future.
In that case, I'll abort this patch series. I don't agree with the `git
rebase' in the lazy form and `git rebase <upstream>' acting differently,
but I already have the rebase.forkpoint set to false to counter it.
It might be better to extend the documentation instead, which will
not distract those who are using the tool just fine already.
That is with the current viewpoints the best option I think.
+ diff -qw expect err &&
Why not "test_cmp expect actual" like everybody else?
As said in the initial patch series and the comment above the tests:
There is one point where I'm a little confused, the `test_cmp' function in the
testsuite doesn't like the output that is captured from STDERR, it seems that
there is a difference in regards to whitespace. My workaround is to use
`diff -wq`. I don't know if this is an accepted solution.
That's why.
Cheers,
Wesley
--
Wesley
Why not both?
