Re: Possible git bug

Wesley Schwengle [off-list ref] writes:

I feel like it is a bad default, it caught me by surprise.

I tend to agree.  It seems that d44e7126 (pull: support rebased
upstream + fetch + pull --rebase, 2009-07-19) started it, probably
by mistake, which was partially corrected by ad8261d2 (rebase: use
reflog to find common base with upstream, 2013-12-09).

The thread that contains

  https://lore.kernel.org/git/xmqq7gbdzsvt.fsf@gitster.dls.corp.google.com/

seems to have resulted in the design of the current behaviour, where 
the discussion refers to an even older discussion thread:

https://lore.kernel.org/git/d8e9f102609ee4502f579cb4ce872e0a40756204.1381949622.git.john@keeping.me.uk/

	Side note: I am kind-of surprised that I contributed the
	core computation of the fork-point logic, even though I
	wasn't buying it is a good feature back then.

In any case, updating the documentation to refer to the configuraion
variable that tweaks the default for --fork-point would be a good
near-term thing to do, but in the longer term, I think it may make
sense to fix this "surprise" and transition the default over time,
i.e.

 (1) when "git rebase" is run without --[no-]fork-point from the
     command line, and without rebase.forkpoint configuration
     variable in effect, give a warning that says we'll change the
     default to 'false' and the users who want to can use the
     configuration variable to force it to 'true'.  Update the
     documentation to say the special casing of "If <upstream> is
     not specified, --fork-point option is assumed" will be changed
     in the future.

     Ship such a version of Git and wait for several development
     cycles.


 (2) flip the default and remove the warning.  Update the
     documentation.

As for the patch. The reason why --fork-point is default I do not
know, but how to disable it isn't documented and I think it should. It
is hidden in the source code and the release notes of 2.31.0. It
should be more visible. Which is the reason I submitted the patch.

Certainly.

"git config --help" is the only end-user facing place the reference
from the configuration variable to the command line option is found.
We should also have a backreference from the command line option to
the configuration variable.

On 9/16/21 5:52 PM, Junio C Hamano wrote:

Wesley Schwengle [off-list ref] writes:

quoted

As for the patch. The reason why --fork-point is default I do not
know, but how to disable it isn't documented and I think it should. It
is hidden in the source code and the release notes of 2.31.0. It
should be more visible. Which is the reason I submitted the patch.

Certainly.

 > In any case, updating the documentation to refer to the configuraion
 > variable that tweaks the default for --fork-point would be a good
 > near-term thing to do, but in the longer term, I think it may make
 > sense to fix this "surprise" and transition the default over time,
 > i.e.
 >
 > "git config --help" is the only end-user facing place the reference
 > from the configuration variable to the command line option is found.
 > We should also have a backreference from the command line option to
 > the configuration variable.

A simple reference in the documentation would be a good first step and 
the change of the default can than happen over multiple iterations/versions.

Cheers,
Wesley

-- 
Wesley Schwengle
E: wesley@schwengle.net