Re: Possible git bug

[Junio C Hamano <gitster@pobox.com>]

wesley@schwengle.net writes:

> On 9/16/21 8:07 AM, Wesley Schwengle wrote:
>  
>> New question, is there a way to tell rebase to NOT use fork-point via 
>> git-config in this situation?
>
> I seem to have found the answer in the source code: rebase.forkpoint exists.
>
> Would you accept the following patch that adds the following text to the
> documentation?

Not so fast.

Earlier you said:

> ... When you have an upstream configured and you don't specify
> it on the command line, --fork-point is used, while if you specify the 
> upstream --no-fork-point is used. `git rebase master --fork-point'
> exhibits the same as I was seeing. Although I'm now completely
> confused by this behavior. It doesn't make sense to me.
>
> This happens:
>
> We are on a branch, we merge it into another branch.
> We undo the merge because reasons.
> Now we git rebase, without the upstream, because we've set it.
> Fork-point is used now, because we haven't specified an upstream, but
> we did set it and git merge-base decides, oh, we had those commits in 
> master but these where dropped so we drop them in this branch as well.

If you feel "It doesn't make sense to me", either

 - the behaviour does not make sense because it is simply buggy, in
   which case, adding a sentence to the documentation and explaining
   how not to use it is missing the point---don't you rather want it
   to behave in a way that makes sense to you instead?

or

 - it appears as nonsense to you only because your understanding of
   the behaviour is faulty but the feature is working correctly and
   is not a bug, in which case, adding a sentence to the
   documentation and explaining how not to use it is missing the
   point---don't you rather want the existing documentation extended
   to help you and other users to understand the behaviour better
   first?

Between "buggy behaviour" and "bad documentation of a well-designed
behaviour", I offhand do not know which side "--fork-point" is for
this particular case, but I've always felt that it is a bad
heuristic that should be used with care, and my gut feeling is it
might be the third possibility: "bad heuristic that sometimes
misbehave badly and that is unfixable".  If that is the case,
perhaps the documentation should tell readers the unreliable nature
of the option and warn them to double check the result before
teaching them how to turn it off permanently.

Thanks.