Re: [PATCH] add --interactive: allow `update` to stage deleted files

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Jun 28 2022, Taylor Blau wrote:

> On Tue, Jun 28, 2022 at 03:35:20PM -0700, Junio C Hamano wrote:
>> The fix looks quite straight-forward.  It is somewhat disappointing
>> that it was caught after this loooong time, but as they say, better
>> late than never.
>
> I had the same thought, but I think that it points to something I've
> suspected privately for a while which is that we don't actually get many
> users to opt-in to features early when they are hidden behind a
> configuration.
>
> I had hoped that things like feature.experimental would cause more users
> to try features that weren't quite ready for prime-time more often, and
> that we'd get more and better feedback as a result.
>
> But I think that this proves that is generally not so. I think we
> should probably err on the side of enabling new features by default so
> long as there is sufficiently low risk, rather than hide them behind
> config. Or at least, not hide them behind a config variable for so long
> (though I am guilty of this myself with the pack.writeReverseIndex,
> which I have been meaning to flip the default on for a little while
> now).

I think we could get quite far by piggy-backing on the advice we emit
when you haven't set user.{email,name}, or otherwise find some minimally
annoying way to ask users to opt-in.

But while an opt-out being the default isn't quite the same as just
changing the code (as you can still toggle it off without downgrading),
that also has the disadvantage that we'd be more conservative about
adding such features, which is partially why we have feature.* in the
first place.

The X-Y problem of how we get early code to users who'd be able to tell
us that it breaks has been discussed several times, and all the
solutions are trade-offs.

One thing I thought of now but I don't think has been brought up before:
I wonder if doing "more stable" (or "LTS"?) releases would be a good
compromise between "early bird" and long-term stability, where we'd just
make every Nth release (say those divisible by 5) have
feature.experimental=false.

But any such scheme also quickly runs into the problem that we're just
not adding a lot of these, and for e.g. the built-in conversion we might
do the whole feature cycle in 3-4 releases, so such "stable" releases
would force us to keep the code around longer.