Re: [RFC PATCH] docs: document upcoming breaking changes

> Hi Patrick
> 
> Thanks putting this together, I think it will be a useful way discussing
> deprecations and removals.
> 
> On 07/05/2024 09:27, Patrick Steinhardt wrote:
> > Over time, Git has grown quite a lot. With this evolution, many ideas
> > that were sensible at the time they were introduced are not anymore and
> > are thus considered to be deprecated. And while some deprecations may be
> > noted in manpages, most of them are actually deprecated in the "hive
> > mind" of the Git community, only.
> > 
> > Introduce a new document that lists upcoming breaking changes to address
> > this issue. This document serves multiple purposes:
> > 
> >    - It is a way to facilitate discussion around proposed deprecations.
> > 
> >    - It allows users to learn about deprecations and speak up in case
> >      they have good reasons why a certain feature should not be
> >      deprecated.
> >
> >    - It states intent and documents where the Git project wants to go.
> 
> Is the plan to use this document to track the progress/status of proposed
> deprecations? For example the config based hooks implementation is stalled
> at the moment and would need some work before we can remove $GIT_DIR/hooks

> > +### Removals
> > +
> > + - git-config(1) has learned to use subcommands that replace implicit actions
> > +   (e.g. `git config foo.bar baz`) as well as the action flags (e.g. `git config
> > +   --unset-all`). The actions will be removed in favor of subcommands.
> > +   Prerequisite for this change is that the new subcommands have been out for at
> > +   least for two years to give script authors time to migrate.
> 
> I agree we want to allow plenty of time for script authors to migrate their
> scripts here.
> 
> > + - githooks(5) can be installed by placing them into `$GIT_DIR/hooks/`. This has
> > +   been a source of multiple remote code execution vulnerabilities.
> 
> I'm not sure about the reasoning here as a hook has to be enabled by the
> user before it is run. There are good reasons to prefer config based hooks
> such as the ability to run multiple scripts per hook event but I don't think
> they are inherently more secure.