git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Wesley Schwengle <wesley@schwengle.net>
Cc: git@vger.kernel.org, me@ttaylorr.com
Subject: Re: Possible git bug
Date: Thu, 16 Sep 2021 14:52:21 -0700	[thread overview]
Message-ID: <xmqqmtocrxwq.fsf@gitster.g> (raw)
In-Reply-To: <3b4270f9-6139-7007-301b-8a084f4336cf@schwengle.net> (Wesley Schwengle's message of "Thu, 16 Sep 2021 15:39:04 -0400")

Wesley Schwengle <wesley@schwengle.net> 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.



  reply	other threads:[~2021-09-16 21:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16  3:29 Possible git bug Wesley Schwengle
2021-09-16  5:37 ` Taylor Blau
2021-09-16 12:07   ` Wesley Schwengle
2021-09-16 12:47     ` wesley
2021-09-16 12:47       ` [PATCH] Document `rebase.forkpoint` in rebase man page wesley
2021-09-16 15:43         ` Junio C Hamano
2021-09-16 21:21           ` Junio C Hamano
2021-09-16 22:35             ` Possible git bug wesley
2021-09-16 22:35               ` [PATCH] Document `rebase.forkpoint` in rebase man page wesley
2021-09-16 22:47                 ` Junio C Hamano
2021-09-16 22:50                   ` Wesley Schwengle
2021-09-16 22:53                     ` Junio C Hamano
2021-09-20 14:34                       ` Wesley Schwengle
2021-09-16 22:46             ` Possible git bug wesley
2021-09-16 22:46               ` [PATCH] Document `rebase.forkpoint` in rebase man page wesley
2021-09-20 16:07                 ` Junio C Hamano
2021-09-16 15:33       ` Possible git bug Junio C Hamano
2021-09-16 19:39         ` Wesley Schwengle
2021-09-16 21:52           ` Junio C Hamano [this message]
2021-09-16 22:30             ` Wesley Schwengle
  -- strict thread matches above, loose matches on Subject: below --
2013-08-14  4:50 Hugh Davenport
2013-08-14  5:42 ` Daniel Knittl-Frank
2013-08-14  6:53   ` Jeff King
2009-01-17 13:52 Damon LaCrosse
2009-01-17 15:16 ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqmtocrxwq.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=wesley@schwengle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).