Re: [PATCH] Revert "Declare both git-switch and git-restore experimental"

From: Martin <git@mfriebe.de>
Date: Feb 20, 2024, 13:34 UTC
Message-ID: <0705b34b-464c-4e7c-88cc-c8507eaf9485@mfriebe.de>
In-Reply-To: <3523e325-98bf-4d2d-847b-28e5c4a85ec5@app.fastmail.com>

On 20/02/2024 10:36, Kristoffer Haugsbakk wrote:

Show 10 quoted lines

> On Tue, Feb 20, 2024, at 10:29, Matthieu Baerts (NGI0) wrote:
>> This reverts commit 4e43b7ff1ea4b6f16b93a432b6718e9ab38749bd.
>> Version 2.44 is approaching, almost 5 years after the introduction of
>> these two commands, it then looks safe to remove this experimental
>> status.
> Is this only based on the amount of time passed? Has there been any
> relevant discussions on the mailing list that discuss how mature these
> commands are and if they should be changed (with presumably a “no” to
> the question about being changed)?
>

Isn't the absence over such a long time of such a discussion in itself a statement? If there had been need for a discussion, would it not have happened by now? Unless, it is assumed that no one is using it, nor has wanted to use it (but has been deterred by the experimental state). Has *every* other additions always had a "relevant" discussion, or would feature in the past have been accepted if no one objected?

Furthermore, if something is functional (I am using it, I can attest it works), and if it had no breaking changes over a very long time, then making/keeping it experimental forever => would that not create a "boy who cried wolf" effect? More and more people will use it. If it gets incompatible broken the outcry will be there. And the documentation as experimental will not lessen that outcry.

On the other hand I have been part of one discussion touching that topic => However this wasn't about: should switch/restore exist at all. It was about if individual options to those commands had been assigned the optimal choice of letter. In that case "-c" for "create", which for users of "git branch" is associated with "copy".

If that is the case, it would be enough to move the experimental to those particular options. And have discussions on those options, rather than the overall existence/naming of switch/restore?

About the "-c":  create vs copy:

> The |-c| and |-C| options have the exact same semantics as |-m| and 
> |-M|, except instead of the branch being renamed, it will be copied to 
> a new name, along with its config and reflog.

"copy" is basically creating a new branch "to a new name" with a copy of certain metadata (config, reflog). The flaw here is in "git branch" which by default list branches, but if give a name (and no option to specify an action) "git branch foo" will change its action to "create".

Anyway, the discussion on "-c" for copy in "switch" is only relevant if there had been a discussion if this is across all git users a common enough action, so it requires a shortcut outside of "git branch". And if it does, and given that copy can't be done without creation, then should "copy" not be an option that in "git switch" should be given together with "create"? e.g. git switch -c newname -X oldbranch [commit-startpoint]" where X is the option that says "copy metadata from" (if it wasn't the worst idea ever, a 2nd "-c" would come to mind. -a "assign" -o "Origin" -r "reflog" -s "source" -w "with" ... though many of them may have potential to conflict too.