Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> It seems pretty haphazard to me, is it even documented somewhere?
>
> I'm talking about an establish process backed up by code, where for
> example I can add an experimental feature in v2.14.0, it'll be subject
> to change & warn unless you configure core.use_experimental=true or
> whatever until v2.16.0, then it'll be considered stable, and changing
> the semantics of any stable feature will require opt-in configuration
> that'll only become default after N more release cycles where N is
> some well-defined number.
>
> Git's deprecation cycles, such as they are, seem to be better
> described as: it'll be noted in the release notes or docs, then left
> for some indeterminate amount of time until we have the argument on a
> case-by-case basis of if/when/how to deal with that specific case.

I do not think we have any "Statutory law" about how to make a
backward-incompatible change in Documentation/; I do not terribly
mind if we see some write-up on the topic there.

Having said that, after getting burned by "git-foo no longer is on
your $PATH" change in 1.6 era [*1*], I think we have been pretty
good at following the same pattern to ease the pain to the users
during transition each time we had to introduce a change that forces
existing users to adjust to the new world order.  Recall how any of
the following (not exhaustive samples) were done: introducing and
making the default value of push.default from "matching" to
"simple"; removal of "git tar-tree"; "git add -u" working on the
whole tree even when run from a subdirectory.  We start by issuing
warning message when a deprecated feature is used or a feature that
will change its default is used, wait for a few releases (depending
on how entrenched its use is), and then finally flip the switch and
remove the message.

You are right to point out that we tend to refrain from setting the
timetable from the beginning of the deprecation dance, and it might
be a good idea to set the exact cut-off date upfront.  I have no
strong opinion.


[References]

*1* https://public-inbox.org/git/?q=gmane:93813