Re: [PATCH v2 1/2] rebase doc: document rebase.useBuiltin

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 16, 2018, 09:35 UTC
Message-ID: <nycvar.QRO.7.76.6.1811161007030.41@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqr2fllmft.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Fri, 16 Nov 2018, Junio C Hamano wrote:

Show 10 quoted lines

> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
> 
> > The rebase.useBuiltin variable introduced in 55071ea248 ("rebase:
> > start implementing it as a builtin", 2018-08-07) was turned on by
> > default in 5541bd5b8f ("rebase: default to using the builtin rebase",
> > 2018-08-08), but had no documentation.
> 
> I actually thought that everybody understood that this was merely an
> aid to be used during the development of the feature and never meant
> to be given to the end users.

It may have been from git.git's point of view, but from Git for Windows' point of view it was always meant to be a real feature flag.

> With my devil's advocate hat on, how much do we trust it as an
> escape hatch?

As you know, only a fraction of the bug reports about the built-in rebase came in from Git for Windows: the autostash-with-submodules bug and the perf-regression one. By my counting that is 2 out of 5 bugs coming in via that route.

One of the reasons for that was that the built-in rebase that was shipped in Git for Windows v2.19.1 was marked as experimental.

And the way I could mark it experimental was by flipping the default to executing the scripted version: https://github.com/git-for-windows/git/commit/cff1a96cfe (you will note that I added the same escape hatch for `git stash` by adding back `git-stash.sh` as `git-legacy-stash.sh` and imitating the same dance as for built-in `rebase`, and I also added back the scripted `git-rebase--interactive.sh` for use by `git-legacy-rebase.sh`).

Meaning: essentially, `rebase.useBuiltin` was defaulting to `false`, and
if a user installed Git for Windows with the experimental built-in rebase,
it was set to `true` in the system config.

There was not a single complaint about the scripted `git rebase` being broken in any way.

So we *do* have some real-world testing of that feature. (Obviously I have no numbers about Git for Windows' usage, apart from download numbers, and they do not say how many users opted in and how many did not, but Git for Windows v2.19.1 was downloaded more than 2.7 million times so far and I think it is safe to assume that some percentage tested that feature.)

> After all, the codepath to hide the "rebase in C" implementation and use
> the scripted version were never in 'master' (or 'next' for that matter)
> with this variable turned off, so I am reasonably sure it had no serious
> exposure to real world usage.

See above for a counter-argument.

> Having said that, assuming that the switching back to scripted
> version works correctly and assuming that we want to expose this to
> end users, I think the patch text makes sense.

Indeed.

I would still love to see the built-in rebase to be used by default in v2.20.0, and I am reasonably sure that the escape hatch works (because, as I told you above, it worked in the reverse, making the built-in rebase an opt-in in Git for Windows v2.19.1).

Ciao, Dscho