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

From: Phillip Wood <phillip.wood123@gmail.com>
Date: May 8, 2024, 13:15 UTC
Message-ID: <077b69f1-cffa-44d5-8614-7f83b63442f8@gmail.com>
In-Reply-To: <fc1a9fa03de7330f79dc56b0f2712834cb236b5a.1715070296.git.ps@pks.im>

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:

Show 14 quoted lines

> 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

Show 7 quoted lines

> +### 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