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

[Phillip Wood <phillip.wood123@gmail.com>]

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.

Best Wishes

Phillip