Re: Possible git bug

>> 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.