{"thread":{"id":"60959","subject":"[PATCH] Revert \"Declare both git-switch and git-restore experimental\"","startedAt":"2024-02-20T09:30:20Z","lastAt":"2024-02-20T19:57:44Z","messageCount":9,"participants":["Matthieu Baerts (NGI0)","Kristoffer Haugsbakk","Matthieu Baerts","Martin","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"488978","messageId":"20240220092957.1296283-2-matttbe@kernel.org","threadId":"60959","inReplyTo":null,"subject":"[PATCH] Revert \"Declare both git-switch and git-restore experimental\"","fromName":"Matthieu Baerts (NGI0)","fromEmail":"matttbe@kernel.org","sentAt":"2024-02-20T09:29:51Z","receivedAt":"2024-02-20T09:30:20Z","isPatch":true,"sender":{"key":"matttbe@kernel.org","avatar":"https://gravatar.com/avatar/eeddb10cd8e676b4c7eda928eeaae8097b1df50c72fbbc3d535d2eee55a633d8?d=mp&s=160"},"body":"This reverts commit 4e43b7ff1ea4b6f16b93a432b6718e9ab38749bd.\n\nRecently, I wanted to recommend the use of git-switch and git-restore\ninstead of git-checkout in new documentation pages. But then, I found\nout that these two commands were still marked as experimental in the\ndocumentation. git-switch and git-restore have been marked as such since\ntheir introduction, in version 2.23.\n\nThat was for good reasons, according to the reverted commit:\n\n> These two commands are basically redesigned git-checkout. We will not\n> have that many opportunities to redo (because we run out of verbs, and\n> that would also increase maintenance cost).\n\nThe reverted commit also mentions this:\n\n> To play it safe, let's declare the two commands experimental in one or\n> two releases. If there is a serious flaw in the UI, we could still fix\n> it. If everything goes well and nobody complains loudly, we can remove\n> the experimental status by reverting this patch.\n\nVersion 2.44 is approaching, almost 5 years after the introduction of\nthese two commands, it then looks safe to remove this experimental\nstatus.\n\nSigned-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>\n---\n\nNotes:\n    Here is a simple 'git revert', as suggested in 4e43b7ff1e (\"Declare both\n    git-switch and git-restore experimental\"), without any conflicts to\n    resolve.\n    \n    BTW, thank you very much for maintaining and still improving this great\n    tool!\n\n Documentation/git-restore.txt | 2 --\n Documentation/git-switch.txt  | 2 --\n 2 files changed, 4 deletions(-)\n\ndiff --git a/Documentation/git-restore.txt b/Documentation/git-restore.txt\nindex 975825b44a..4f5531c440 100644\n--- a/Documentation/git-restore.txt\n+++ b/Documentation/git-restore.txt\n@@ -28,8 +28,6 @@ otherwise from the index. Use `--source` to restore from a different commit.\n See \"Reset, restore and revert\" in linkgit:git[1] for the differences\n between the three commands.\n \n-THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.\n-\n OPTIONS\n -------\n -s <tree>::\ndiff --git a/Documentation/git-switch.txt b/Documentation/git-switch.txt\nindex f38e4c8afa..96cfd9ba52 100644\n--- a/Documentation/git-switch.txt\n+++ b/Documentation/git-switch.txt\n@@ -29,8 +29,6 @@ Switching branches does not require a clean index and working tree\n however if the operation leads to loss of local changes, unless told\n otherwise with `--discard-changes` or `--merge`.\n \n-THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.\n-\n OPTIONS\n -------\n <branch>::\n-- \n2.43.0\n\n"},{"id":"488979","messageId":"3523e325-98bf-4d2d-847b-28e5c4a85ec5@app.fastmail.com","threadId":"60959","inReplyTo":"20240220092957.1296283-2-matttbe@kernel.org","subject":"Re: [PATCH] Revert \"Declare both git-switch and git-restore experimental\"","fromName":"Kristoffer Haugsbakk","fromEmail":"code@khaugsbakk.name","sentAt":"2024-02-20T09:36:02Z","receivedAt":"2024-02-20T09:36:24Z","isPatch":true,"sender":{"key":"code@khaugsbakk.name","avatar":"https://avatars.githubusercontent.com/u/2229597?v=4"},"body":"On Tue, Feb 20, 2024, at 10:29, Matthieu Baerts (NGI0) wrote:\n> This reverts commit 4e43b7ff1ea4b6f16b93a432b6718e9ab38749bd.\n> Version 2.44 is approaching, almost 5 years after the introduction of\n> these two commands, it then looks safe to remove this experimental\n> status.\n\nIs this only based on the amount of time passed? Has there been any\nrelevant discussions on the mailing list that discuss how mature these\ncommands are and if they should be changed (with presumably a “no” to\nthe question about being changed)?\n\n-- \nKristoffer Haugsbakk\n\n"},{"id":"488981","messageId":"95eb92cb-7954-41c0-b542-5169ed5f9892@kernel.org","threadId":"60959","inReplyTo":"3523e325-98bf-4d2d-847b-28e5c4a85ec5@app.fastmail.com","subject":"Re: [PATCH] Revert \"Declare both git-switch and git-restore experimental\"","fromName":"Matthieu Baerts","fromEmail":"matttbe@kernel.org","sentAt":"2024-02-20T09:58:45Z","receivedAt":"2024-02-20T09:59:02Z","isPatch":true,"sender":{"key":"matttbe@kernel.org","avatar":"https://gravatar.com/avatar/eeddb10cd8e676b4c7eda928eeaae8097b1df50c72fbbc3d535d2eee55a633d8?d=mp&s=160"},"body":"Hi Kristoffer,\n\nThank you for your comment.\n\nOn 20/02/2024 10:36, Kristoffer Haugsbakk wrote:\n> On Tue, Feb 20, 2024, at 10:29, Matthieu Baerts (NGI0) wrote:\n>> This reverts commit 4e43b7ff1ea4b6f16b93a432b6718e9ab38749bd.\n>> Version 2.44 is approaching, almost 5 years after the introduction of\n>> these two commands, it then looks safe to remove this experimental\n>> status.\n> \n> Is this only based on the amount of time passed? Has there been any\n> relevant discussions on the mailing list that discuss how mature these\n> commands are and if they should be changed (with presumably a “no” to\n> the question about being changed)?\n\nIt is only based on the amount of time passed, indeed.\n\nI initially wanted to start a discussion on the mailing list: \"is it\nnormal these commands are still marked as experimental?\". Then I saw the\npatch introducing this status, which was suggesting doing a revert in\nversion 2.24 or 2.25. That's why I sent this, to start the discussions\nwith a patch that is ready to apply. Is it not OK to do that here?\n\nAlso, when I quickly looked at the history, I didn't see any behaviour\nchanges since their introduction. Maybe there was a minor change with\ncommit 088018e34d (\"restore: default to HEAD when combining --staged and\n--worktree\"), but it looks more like a fix than a behaviour change.\n\nCheers,\nMatt\n-- \nSponsored by the NGI0 Core fund.\n"},{"id":"488985","messageId":"920a0f61-d30b-49f1-87b3-fb947cb3c33d@app.fastmail.com","threadId":"60959","inReplyTo":"95eb92cb-7954-41c0-b542-5169ed5f9892@kernel.org","subject":"Re: [PATCH] Revert \"Declare both git-switch and git-restore experimental\"","fromName":"Kristoffer Haugsbakk","fromEmail":"code@khaugsbakk.name","sentAt":"2024-02-20T11:36:10Z","receivedAt":"2024-02-20T11:36:33Z","isPatch":true,"sender":{"key":"code@khaugsbakk.name","avatar":"https://avatars.githubusercontent.com/u/2229597?v=4"},"body":"On Tue, Feb 20, 2024, at 10:58, Matthieu Baerts wrote:\n> Hi Kristoffer,\n>\n> Thank you for your comment.\n>\n> On 20/02/2024 10:36, Kristoffer Haugsbakk wrote:\n>> On Tue, Feb 20, 2024, at 10:29, Matthieu Baerts (NGI0) wrote:\n>>> This reverts commit 4e43b7ff1ea4b6f16b93a432b6718e9ab38749bd.\n>>> Version 2.44 is approaching, almost 5 years after the introduction of\n>>> these two commands, it then looks safe to remove this experimental\n>>> status.\n>>\n>> Is this only based on the amount of time passed? Has there been any\n>> relevant discussions on the mailing list that discuss how mature these\n>> commands are and if they should be changed (with presumably a “no” to\n>> the question about being changed)?\n>\n> It is only based on the amount of time passed, indeed.\n>\n> I initially wanted to start a discussion on the mailing list: \"is it\n> normal these commands are still marked as experimental?\". Then I saw the\n> patch introducing this status, which was suggesting doing a revert in\n> version 2.24 or 2.25. That's why I sent this, to start the discussions\n> with a patch that is ready to apply. Is it not OK to do that here?\n>\n> Also, when I quickly looked at the history, I didn't see any behaviour\n> changes since their introduction. Maybe there was a minor change with\n> commit 088018e34d (\"restore: default to HEAD when combining --staged and\n> --worktree\"), but it looks more like a fix than a behaviour change.\n\nAll good reasons.\n\nThe only reason why I ask is because I was vaguely aware of some\ndiscussions (don’t know how long ago) where someone was skeptical about\nchanging one of the two experimental commands, and then someone else in\nturn expressed some frustration about this concern since they are after\nall marked experimental. And the context was some UI/UX problems with\nthe command.\n\nBut we’ll see.\n\n-- \nKristoffer Haugsbakk\n\n"},{"id":"488988","messageId":"0705b34b-464c-4e7c-88cc-c8507eaf9485@mfriebe.de","threadId":"60959","inReplyTo":"3523e325-98bf-4d2d-847b-28e5c4a85ec5@app.fastmail.com","subject":"Re: [PATCH] Revert \"Declare both git-switch and git-restore experimental\"","fromName":"Martin","fromEmail":"git@mfriebe.de","sentAt":"2024-02-20T13:34:00Z","receivedAt":"2024-02-20T13:34:02Z","isPatch":true,"sender":{"key":"git@mfriebe.de","avatar":null},"body":"On 20/02/2024 10:36, Kristoffer Haugsbakk wrote:\n> On Tue, Feb 20, 2024, at 10:29, Matthieu Baerts (NGI0) wrote:\n>> This reverts commit 4e43b7ff1ea4b6f16b93a432b6718e9ab38749bd.\n>> Version 2.44 is approaching, almost 5 years after the introduction of\n>> these two commands, it then looks safe to remove this experimental\n>> status.\n> Is this only based on the amount of time passed? Has there been any\n> relevant discussions on the mailing list that discuss how mature these\n> commands are and if they should be changed (with presumably a “no” to\n> the question about being changed)?\n>\n\nIsn't the absence over such a long time of such a discussion in itself a \nstatement?\nIf there had been need for a discussion, would it not have happened by now?\nUnless, it is assumed that no one is using it, nor has wanted to use it \n(but has been deterred by the experimental state).\nHas *every* other additions always had a \"relevant\" discussion, or would \nfeature in the past have been accepted if no one objected?\n\n\nFurthermore, if something is functional (I am using it, I can attest it \nworks), and if it had no breaking changes over a very long time, then \nmaking/keeping it experimental forever => would that not create a \"boy \nwho cried wolf\" effect? More and more people will use it. If it gets \nincompatible broken the outcry will be there. And the documentation as \nexperimental will not lessen that outcry.\n\n\nOn the other hand I have been part of one discussion touching that topic \n=> However this wasn't about: should switch/restore exist at all. It was \nabout if individual options to those commands had been assigned the \noptimal choice of letter. In that case \"-c\" for \"create\", which for \nusers of \"git branch\" is associated with \"copy\".\n\nIf that is the case, it would be enough to move the experimental to \nthose particular options. And have discussions on those options, rather \nthan the overall existence/naming of switch/restore?\n\n\nAbout the \"-c\":  create vs copy:\n> The |-c| and |-C| options have the exact same semantics as |-m| and \n> |-M|, except instead of the branch being renamed, it will be copied to \n> a new name, along with its config and reflog.\n\"copy\" is basically creating a new branch \"to a new name\" with a copy of \ncertain metadata (config, reflog).\nThe flaw here is in \"git branch\" which by default list branches, but if \ngive a name (and no option to specify an action) \"git branch foo\" will \nchange its action to \"create\".\n\nAnyway, the discussion on \"-c\" for copy in \"switch\" is only relevant if \nthere had been a discussion if this is across all git users a common \nenough action, so it requires a shortcut outside of \"git branch\". And if \nit does, and given that copy can't be done without creation, then should \n\"copy\" not be an option that in \"git switch\" should be given together \nwith \"create\"? e.g. git switch -c newname -X oldbranch  \n[commit-startpoint]\" where X is the option that says \"copy metadata \nfrom\" (if it wasn't the worst idea ever, a 2nd \"-c\" would come to mind. \n-a \"assign\" -o \"Origin\" -r \"reflog\" -s \"source\" -w \"with\" ... though \nmany of them may have potential to conflict too.\n\n\n"},{"id":"488990","messageId":"e6f77156-bac7-4ee1-ac88-64627e629401@app.fastmail.com","threadId":"60959","inReplyTo":"dfaed16c-5e24-4dfb-8afd-b703134e5ada@mfriebe.de","subject":"Re: [PATCH] Revert \"Declare both git-switch and git-restore experimental\"","fromName":"Kristoffer Haugsbakk","fromEmail":"code@khaugsbakk.name","sentAt":"2024-02-20T16:20:23Z","receivedAt":"2024-02-20T16:20:45Z","isPatch":true,"sender":{"key":"code@khaugsbakk.name","avatar":"https://avatars.githubusercontent.com/u/2229597?v=4"},"body":"On Tue, Feb 20, 2024, at 14:32, Martin wrote:\n> On 20/02/2024 10:36, Kristoffer Haugsbakk wrote:\n>> On Tue, Feb 20, 2024, at 10:29, Matthieu Baerts (NGI0) wrote:\n>>\n>>> This reverts commit 4e43b7ff1ea4b6f16b93a432b6718e9ab38749bd.\n>>> Version 2.44 is approaching, almost 5 years after the introduction of\n>>> these two commands, it then looks safe to remove this experimental\n>>> status.\n>>>\n>> Is this only based on the amount of time passed? Has there been any\n>> relevant discussions on the mailing list that discuss how mature these\n>> commands are and if they should be changed (with presumably a “no” to\n>> the question about being changed)?\n>>\n>>\n>\n> Isn't the absence over such a long time of such a discussion in itself a statement?\n> If there had been need for a discussion, would it not have happened by now?\n\nI don’t know if there has been an absence of it. That’s why I asked.\n\n-- \nKristoffer Haugsbakk\n"},{"id":"489002","messageId":"xmqqzfvvovva.fsf@gitster.g","threadId":"60959","inReplyTo":"920a0f61-d30b-49f1-87b3-fb947cb3c33d@app.fastmail.com","subject":"Re: [PATCH] Revert \"Declare both git-switch and git-restore experimental\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-02-20T18:04:25Z","receivedAt":"2024-02-20T18:04:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kristoffer Haugsbakk\" <code@khaugsbakk.name> writes:\n\n> The only reason why I ask is because I was vaguely aware of some\n> discussions (don’t know how long ago) where someone was skeptical about\n> changing one of the two experimental commands, and then someone else in\n> turn expressed some frustration about this concern since they are after\n> all marked experimental. And the context was some UI/UX problems with\n> the command.\n\nThere was a discussion to further make \"switch\" deviate from\n\"checkout\" by taking advantage of its experimental status [*1*], for\nexample.\n\nBeing marked as \"EXPERIMENTAL\" allows us to redefine the behaviour\nin a way that would break existing users, like changing what the\n\"-c\" option means completely (so that folks who are used to say\n\"switch -c blah\" will be surprised next time they type that command,\nbut they cannot complain).  Once you remove the label, you no longer\nhave such a freedom to even imagine departing from the existing\nbehaviour (I wrote essentially the same thing before [*2*]).  Are we\nready to paint us into such a corner yet?  Is \"switch/restore\" perfect\nand do not need departing changes anymore?\n\n\n[References]\n\n*1* https://lore.kernel.org/git/211021.86wnm6l1ip.gmgdl@evledraar.gmail.com/\n*2* https://lore.kernel.org/git/xmqqzg6eocmi.fsf@gitster.g/\n"},{"id":"489008","messageId":"0174d19e-abc4-4d2e-a60d-e7df52b74d0b@kernel.org","threadId":"60959","inReplyTo":"xmqqzfvvovva.fsf@gitster.g","subject":"Re: [PATCH] Revert \"Declare both git-switch and git-restore experimental\"","fromName":"Matthieu Baerts","fromEmail":"matttbe@kernel.org","sentAt":"2024-02-20T18:39:33Z","receivedAt":"2024-02-20T18:39:36Z","isPatch":true,"sender":{"key":"matttbe@kernel.org","avatar":"https://gravatar.com/avatar/eeddb10cd8e676b4c7eda928eeaae8097b1df50c72fbbc3d535d2eee55a633d8?d=mp&s=160"},"body":"Hi Junio,\n\nThank you for your reply!\n\nOn 20/02/2024 7:04 pm, Junio C Hamano wrote:\n> \"Kristoffer Haugsbakk\" <code@khaugsbakk.name> writes:\n> \n>> The only reason why I ask is because I was vaguely aware of some\n>> discussions (don’t know how long ago) where someone was skeptical about\n>> changing one of the two experimental commands, and then someone else in\n>> turn expressed some frustration about this concern since they are after\n>> all marked experimental. And the context was some UI/UX problems with\n>> the command.\n> \n> There was a discussion to further make \"switch\" deviate from\n> \"checkout\" by taking advantage of its experimental status [*1*], for\n> example.\n\nI appreciate the references, thank you! It is interesting to note\nchanges have been proposed a few years ago, but none have been applied.\n\n> Being marked as \"EXPERIMENTAL\" allows us to redefine the behaviour\n> in a way that would break existing users, like changing what the\n> \"-c\" option means completely (so that folks who are used to say\n> \"switch -c blah\" will be surprised next time they type that command,\n> but they cannot complain).\n\nPersonally, I think I would complain, and go back to git-checkout :-)\n\n> Once you remove the label, you no longer\n> have such a freedom to even imagine departing from the existing\n> behaviour (I wrote essentially the same thing before [*2*]).  Are we\n> ready to paint us into such a corner yet?\n\nI'm not involved in this project, but I think after a few versions /\nyears, it is hard to still keep this experimental status. I understand\nit is tempting to keep it, but I think it is now too late. Despite the\nnow old label, you probably already no longer have such freedom to\nradically change their behaviours, no?\n\n> Is \"switch/restore\" perfect\n> and do not need departing changes anymore?\nTo me, they don't need departing changes. If they are still experimental\nafter 5 years, it is hard to recommend them :)\n\nCheers,\nMatt\n-- \nSponsored by the NGI0 Core fund.\n"},{"id":"489022","messageId":"86226be8-7a1d-454a-b3dc-7d5921b47329@mfriebe.de","threadId":"60959","inReplyTo":"xmqqzfvvovva.fsf@gitster.g","subject":"Re: [PATCH] Revert \"Declare both git-switch and git-restore experimental\"","fromName":"Martin","fromEmail":"lists@mfriebe.de","sentAt":"2024-02-20T19:57:42Z","receivedAt":"2024-02-20T19:57:44Z","isPatch":true,"sender":{"key":"lists@mfriebe.de","avatar":null},"body":"On 20/02/2024 19:04, Junio C Hamano wrote:\n\n> [References]\n> \n> *1* https://lore.kernel.org/git/211021.86wnm6l1ip.gmgdl@evledraar.gmail.com/\n> *2* https://lore.kernel.org/git/xmqqzg6eocmi.fsf@gitster.g/\n> \n\n From 2\n> I think the \"switch\" was written exactly for such a transition so that folks who\n> wanted a different behaviour do not have to break existing users of \"checkout\".\n\nYet then the table in link 1 suggests to re-use -c and -m in the old \nstyle, the way the currently are used in \"git branch\"\n\n\"Introducing a new behaviour\" is exactly not having to copy old meanings \nof options...\n\nAs I wrote\n> 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\". \n\nIf \"git branche\" actually had needed an option to change its action to \ncreate, what would it have been? --create or -c ?\n\nAnd -n (as suggested in the table) is strongly associated with dry-run. \n(not only in git)\n\n\nIf I look at the suggestion to replace -m by --merge, just so that -m \ncan be \"move\", then I seriously ask, what happens more often:\n- Someone switching to a branch while having modifications in their \nworktree (needing to merge)\n- Someone creating a new branch, wanting to copy reflog/options\n\nGiven not only that switching to a new branch happens more often than \ncreating one (and thereby makes it alt least plausible, that the -m as \n\"merge\" is required more often)..., but also that \"git switch\" is more \nabout switching than creating branches..., I believe that -m as \"merge\" \nis entirely the better choice.\n\nFor the \"git branch\" features, if \"git switch\" should support them, they \ncould easily be made available as\n--cc  create and copy\n--mv  move\n\nThey - by all likelihood - are used less often, and should be the long \noptions. And a 2 letter long option is still easy to use.\n\n"}]}