{"thread":{"id":"55617","subject":"git switch/restore, still experimental?","startedAt":"2021-05-04T10:32:58Z","lastAt":"2021-05-11T07:15:30Z","messageCount":25,"participants":["Gábor Farkas","Felipe Contreras","Elijah Newren","Eric Sunshine","Ævar Arnfjörð Bjarmason","Johannes Schindelin","Randall S. Becker","Sergey Organov","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"423569","messageId":"CAPiPmQnb=XMaF2+YkryEbiX8zA=jwa5y=fbAGk9jpCExpbS4Rw@mail.gmail.com","threadId":"55617","inReplyTo":null,"subject":"git switch/restore, still experimental?","fromName":"Gábor Farkas","fromEmail":"gabor.farkas@gmail.com","sentAt":"2021-05-04T10:32:44Z","receivedAt":"2021-05-04T10:32:58Z","isPatch":false,"sender":{"key":"gabor.farkas@gmail.com","avatar":null},"body":"hi,\n\nthe \"git switch\" and \"git restore\" commands were released two years\nago, but the manpage still says \"THIS COMMAND IS EXPERIMENTAL. THE\nBEHAVIOR MAY CHANGE.\".\n\ni'd love to use them, but this warning gives me pause, perhaps i\nshould wait until it stops being experimental, i worry that it might\nchange in behavior unexpectedly and cause problems for me.\n\nconsidering that they were released two years ago, could the\nexperimental-warning be removed now?\n\nthanks,\ngabor\n"},{"id":"423605","messageId":"6091a67824041_b32c320862@natae.notmuch","threadId":"55617","inReplyTo":"CAPiPmQnb=XMaF2+YkryEbiX8zA=jwa5y=fbAGk9jpCExpbS4Rw@mail.gmail.com","subject":"RE: git switch/restore, still experimental?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-04T19:54:32Z","receivedAt":"2021-05-04T19:54:41Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Gábor Farkas wrote:\n> the \"git switch\" and \"git restore\" commands were released two years\n> ago, but the manpage still says \"THIS COMMAND IS EXPERIMENTAL. THE\n> BEHAVIOR MAY CHANGE.\".\n> \n> i'd love to use them, but this warning gives me pause, perhaps i\n> should wait until it stops being experimental, i worry that it might\n> change in behavior unexpectedly and cause problems for me.\n\nIt's precisely because the behavior may change that they are labeled as\nexperimental.\n\nI have 15 of experience using git, and I have tried to use them but to\nme they are too cumbersome.\n\nFor example I would expect this to work:\n\n  git restore @~ -- file\n\nBut it doesn't, I need to specify `-s @~`.\n\ngit checkout is more user-friendly to me, so purpose of git restore is\ndefeated.\n\nIf the interface is changed, perhaps it will be useful to me. It isn't\nat the moment.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"423638","messageId":"CABPp-BHBcjSQbkotrzwDtVRSC-qqjEyP4m=biY-0+=Jdg9ETQw@mail.gmail.com","threadId":"55617","inReplyTo":"CAPiPmQnb=XMaF2+YkryEbiX8zA=jwa5y=fbAGk9jpCExpbS4Rw@mail.gmail.com","subject":"Re: git switch/restore, still experimental?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-05-05T03:46:30Z","receivedAt":"2021-05-05T03:47:04Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com> wrote:\n>\n> hi,\n>\n> the \"git switch\" and \"git restore\" commands were released two years\n> ago, but the manpage still says \"THIS COMMAND IS EXPERIMENTAL. THE\n> BEHAVIOR MAY CHANGE.\".\n>\n> i'd love to use them, but this warning gives me pause, perhaps i\n> should wait until it stops being experimental, i worry that it might\n> change in behavior unexpectedly and cause problems for me.\n>\n> considering that they were released two years ago, could the\n> experimental-warning be removed now?\n>\n> thanks,\n> gabor\n\nThis probably makes sense.  The author of switch and restore isn't\ninvolved in the git project anymore.  He decided to work on other\nthings, which was and is a big loss for us.  I think others (myself\nincluded) didn't know all the things that might have been in Duy's\nhead that he wanted to verify were working well before marking this as\ngood, but these two commands have generally been very well received\nand it has been a few years.  Personally, I'm not aware of anything\nthat we'd need or want to change with these commands.\n\nThat said, we're only a few weeks from -rc0, and I'd rather remove the\nexperimental label early in a release cycle, so maybe this would be a\ngood thing to do after the June git-2.32 release.  That'd give plenty\nof time for others to chime in with anything they might be aware of\nthat they want or need fixed.\n\nThanks for flagging this.\n\nElijah\n"},{"id":"423640","messageId":"CAPig+cQHmfTBpa=5nRHD1cceLSucQW8TgxFm3_OyOFpbOOPuig@mail.gmail.com","threadId":"55617","inReplyTo":"CABPp-BHBcjSQbkotrzwDtVRSC-qqjEyP4m=biY-0+=Jdg9ETQw@mail.gmail.com","subject":"Re: git switch/restore, still experimental?","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-05-05T04:01:42Z","receivedAt":"2021-05-05T04:02:03Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, May 4, 2021 at 11:47 PM Elijah Newren <newren@gmail.com> wrote:\n> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com> wrote:\n> > the \"git switch\" and \"git restore\" commands were released two years\n> > ago, but the manpage still says \"THIS COMMAND IS EXPERIMENTAL. THE\n> > BEHAVIOR MAY CHANGE.\".\n> >\n> > considering that they were released two years ago, could the\n> > experimental-warning be removed now?\n>\n> This probably makes sense.  The author of switch and restore isn't\n> involved in the git project anymore.  He decided to work on other\n> things, which was and is a big loss for us.  I think others (myself\n> included) didn't know all the things that might have been in Duy's\n> head that he wanted to verify were working well before marking this as\n> good, but these two commands have generally been very well received\n> and it has been a few years.  Personally, I'm not aware of anything\n> that we'd need or want to change with these commands.\n\nAs a point of interest, Duy introduced multiple worktree support\n(which eventually became git-worktree) in late 2014, and it's still\nmarked as experimental in the documentation (though not in loud\nuppercase).\n"},{"id":"423652","messageId":"877dkdwgfe.fsf@evledraar.gmail.com","threadId":"55617","inReplyTo":"CABPp-BHBcjSQbkotrzwDtVRSC-qqjEyP4m=biY-0+=Jdg9ETQw@mail.gmail.com","subject":"Re: git switch/restore, still experimental?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-05T11:09:47Z","receivedAt":"2021-05-05T11:47:39Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, May 04 2021, Elijah Newren wrote:\n\n> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com> wrote:\n>>\n>> hi,\n>>\n>> the \"git switch\" and \"git restore\" commands were released two years\n>> ago, but the manpage still says \"THIS COMMAND IS EXPERIMENTAL. THE\n>> BEHAVIOR MAY CHANGE.\".\n>>\n>> i'd love to use them, but this warning gives me pause, perhaps i\n>> should wait until it stops being experimental, i worry that it might\n>> change in behavior unexpectedly and cause problems for me.\n>>\n>> considering that they were released two years ago, could the\n>> experimental-warning be removed now?\n>>\n>> thanks,\n>> gabor\n>\n> This probably makes sense.  The author of switch and restore isn't\n> involved in the git project anymore.  He decided to work on other\n> things, which was and is a big loss for us.  I think others (myself\n> included) didn't know all the things that might have been in Duy's\n> head that he wanted to verify were working well before marking this as\n> good, but these two commands have generally been very well received\n> and it has been a few years.  Personally, I'm not aware of anything\n> that we'd need or want to change with these commands.\n\nI am.\n\nI think it's quite confusing that \"git switch\" doesn't switch to a new\n\"doesnotexist\" branch on something like:\n\n    git switch doesnotexist\n\nBut requires:\n\n    git switch -c doesnotexist\n\nI mean, I see why. You don't want a typo of \"master\" as \"maaster\" to\ncreate a new \"maaster\" branch, so really that's out. But it really\nshould be:\n\n    # -n or -N for --new / --new --force (the latter just in case of a\n    # race, and just for consistency)\n    git switch -n doesnotexist\n\nThe design choice of squatting on \"-c\" for \"create\" as opposed to \"copy\"\nas implemented in 52d59cc6452 (branch: add a --copy (-c) option to go\nwith --move (-m), 2017-06-18) has the knock-on effect that we can't\nmirror the \"git branch\" UI. I.e. to make \"switch\" be \"branch with\ncheckout\" for these common cases.\n\nI.e.:\n\n    # copies a branch and config from old->new (or -C for --force)\n    git branch -c old new\n    # just creates a \"new\" starting at \"old\", but no copying!\n    git switch -c new old\n\nAnd:\n\n   # Moves a branch (or -M for --force)\n   git branch -m old new\n\nThat last one we can't have either because \"switch\" squats on \"-m\" for\n\"--merge\", which I daresay is a much more obscure use-case not deserving\nof a short option than \"rename and switch to\".\n\nIn summary, I think it should be changed to act like this:\n    \n    |---------------------------+------------------------+---------------------------|\n    | What                      | Now                    | New                       |\n    |---------------------------+------------------------+---------------------------|\n    | Switch                    | git switch existing    | git switch existing       |\n    | Error                     | git switch nonexisting | <no change (errors)>      |\n    | Switch with --merge       | git switch -m branch   | git switch --merge branch |\n    | Create                    | git switch -c new      | git switch -n new         |\n    | Create from existing      | N/A                    | git switch -c new [<old>] |\n    | Move & switch to existing | N/A                    | git switch -m new [<old>] |\n    |---------------------------+------------------------+---------------------------|\n\nOne thing that sucks about my proposal is that it would be squatting on\n\"-n\" for \"new\" as opposed to \"--dry-run\".\n\nIt would be nice if switch/checkout learned a --dry-run mode, I don't\nlike e.g. \"fetch\" having a \"-n\" that isn't \"--dry-run\", but can't think\nof a better option in the switch case.\n\nIn its current state I find \"git switch\" to be unusable. That sounds\nlike dramatic hyperbole, but I'm serious.\n\nAs much as I applaud the effort to move git's UI forward in this\nparticular case it's doomed to be only skin-deep because of that\nunfortunate initial design choice of sort-of acting like \"git branch\nwith checkout\", but squatting on \"-c/-C/-m\".\n\nI.e. to me the ideal end state would be to deprecate (or at least\nwarn/discourage) the \"git branch -m\" case where it does its own checkout\n(but for nothing else), and to make \"git switch\" a \"branch with\ncheckout\" with the same -c/-C/-m/-M semantics, just also with a -n/-N\nfor \"create first\".\n\nSo at the end of the day you still have to use \"git branch\" for these\ncommon (at least for me) operations of copy/move, *and* maintain a\nmental model that \"-c\" means \"xyz\" here, but \"abc\" there.\n\nThe \"switch\" command also solves the very real problem (and I believe\nthis was the main motivation) of not knowing beforehand if \"checkout\"\nwill interpret your \"foo\" as a file, a branch or whatever. I find it\neasier to solve that (I'm aware that it's not a 100% solution) by\nconsistently using \"--\" to escape path names, rather than needing to\nmentally model the difference in \"-c/-C/-m\" behavior.\n"},{"id":"423687","messageId":"nycvar.QRO.7.76.6.2105051554250.50@tvgsbejvaqbjf.bet","threadId":"55617","inReplyTo":"CABPp-BHBcjSQbkotrzwDtVRSC-qqjEyP4m=biY-0+=Jdg9ETQw@mail.gmail.com","subject":"Re: git switch/restore, still experimental?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2021-05-05T14:18:11Z","receivedAt":"2021-05-05T14:18:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Elijah,\n\nOn Tue, 4 May 2021, Elijah Newren wrote:\n\n> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com> wrote:\n> >\n> > the \"git switch\" and \"git restore\" commands were released two years\n> > ago, but the manpage still says \"THIS COMMAND IS EXPERIMENTAL. THE\n> > BEHAVIOR MAY CHANGE.\".\n> >\n> > i'd love to use them, but this warning gives me pause, perhaps i\n> > should wait until it stops being experimental, i worry that it might\n> > change in behavior unexpectedly and cause problems for me.\n> >\n> > considering that they were released two years ago, could the\n> > experimental-warning be removed now?\n>\n> This probably makes sense.  The author of switch and restore isn't\n> involved in the git project anymore.  He decided to work on other\n> things, which was and is a big loss for us.  I think others (myself\n> included) didn't know all the things that might have been in Duy's\n> head that he wanted to verify were working well before marking this as\n> good, but these two commands have generally been very well received\n> and it has been a few years.  Personally, I'm not aware of anything\n> that we'd need or want to change with these commands.\n\nI think that part of the intention to mark this as experimental was to\ngather feedback about the commands. After all, the goal was to improve the\nuser experience of Git (because `git checkout` does too many things, and\nits major accomplishment is to confuse literally every single new Git\nuser).\n\nHowever, that hope never was fulfilled if I may say so, we simply did not\nattract the best-suited experts to this mailing list, not if what we set\nout was to improve usability.\n\nWhich leaves us with two hard choices regarding switch/restore, none of\nthem really being comfortable:\n\n- we scrap switch/restore because their usability is not really all that\n  improved relative to `git checkout`.\n\n- we leave switch/restore as-are (because by now, changing the options or\n  the design would be almost certainly disruptive to users who already\n  tried to adopt the new commands, I being one of those users).\n\nI say that neither of them is a really splendid choice because the\noriginal goal is not only not accomplished, but I would say it is even\nharder now than it was when we accepted switch/restore into an official\nrelease, because of that experience with switch/restore. We simply do not\nhave the right expertise on this list, and therefore anything we do will\nalways have that \"UX designed by an engineer\" feel.\n\nSo I'm not sure what to do, either.\n\nCiao,\nDscho\n\n> That said, we're only a few weeks from -rc0, and I'd rather remove the\n> experimental label early in a release cycle, so maybe this would be a\n> good thing to do after the June git-2.32 release.  That'd give plenty\n> of time for others to chime in with anything they might be aware of\n> that they want or need fixed.\n>\n> Thanks for flagging this.\n>\n> Elijah\n>\n"},{"id":"423688","messageId":"00af01d741ba$b916a330$2b43e990$@nexbridge.com","threadId":"55617","inReplyTo":"nycvar.QRO.7.76.6.2105051554250.50@tvgsbejvaqbjf.bet","subject":"RE: git switch/restore, still experimental?","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-05-05T14:26:59Z","receivedAt":"2021-05-05T14:27:12Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 5, 2021 10:18 AM, Johannes Schindelin wrote:\n>On Tue, 4 May 2021, Elijah Newren wrote:\n>> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com>\n>wrote:\n>> >\n>> > the \"git switch\" and \"git restore\" commands were released two years\n>> > ago, but the manpage still says \"THIS COMMAND IS EXPERIMENTAL. THE\n>> > BEHAVIOR MAY CHANGE.\".\n>> >\n>> > i'd love to use them, but this warning gives me pause, perhaps i\n>> > should wait until it stops being experimental, i worry that it might\n>> > change in behavior unexpectedly and cause problems for me.\n>> >\n>> > considering that they were released two years ago, could the\n>> > experimental-warning be removed now?\n>>\n>> This probably makes sense.  The author of switch and restore isn't\n>> involved in the git project anymore.  He decided to work on other\n>> things, which was and is a big loss for us.  I think others (myself\n>> included) didn't know all the things that might have been in Duy's\n>> head that he wanted to verify were working well before marking this as\n>> good, but these two commands have generally been very well received\n>> and it has been a few years.  Personally, I'm not aware of anything\n>> that we'd need or want to change with these commands.\n>\n>I think that part of the intention to mark this as experimental was to gather\n>feedback about the commands. After all, the goal was to improve the user\n>experience of Git (because `git checkout` does too many things, and its major\n>accomplishment is to confuse literally every single new Git user).\n>\n>However, that hope never was fulfilled if I may say so, we simply did not attract\n>the best-suited experts to this mailing list, not if what we set out was to improve\n>usability.\n>\n>Which leaves us with two hard choices regarding switch/restore, none of them\n>really being comfortable:\n>\n>- we scrap switch/restore because their usability is not really all that\n>  improved relative to `git checkout`.\n\nPlease do not do that. Switch/restore is much easier to understand for new users. The semantics are also more consistent with what others have done with git over the years anyway (EGit as an example). I have users who have transitioned because the commands make sense. They have not hit any missing bits in their workflows.\n\n>- we leave switch/restore as-are (because by now, changing the options or\n>  the design would be almost certainly disruptive to users who already\n>  tried to adopt the new commands, I being one of those users).\n\nI think we should work on the commands to cover between them (well... and reset) to functionally cover what checkout does. Leaving them as-is, I think is not a viable option. People do know these are experimental and not to use in scripts - we can hope anyway.\n\n>I say that neither of them is a really splendid choice because the original goal is\n>not only not accomplished, but I would say it is even harder now than it was\n>when we accepted switch/restore into an official release, because of that\n>experience with switch/restore. We simply do not have the right expertise on\n>this list, and therefore anything we do will always have that \"UX designed by an\n>engineer\" feel.\n\nMy thoughts anyway.\n\n-Randall\n\n"},{"id":"423700","messageId":"6092da0ccf4e9_1d24520833@natae.notmuch","threadId":"55617","inReplyTo":"877dkdwgfe.fsf@evledraar.gmail.com","subject":"Re: git switch/restore, still experimental?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-05T17:46:52Z","receivedAt":"2021-05-05T18:02:51Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> In summary, I think it should be changed to act like this:\n>     \n>     |---------------------------+------------------------+---------------------------|\n>     | What                      | Now                    | New                       |\n>     |---------------------------+------------------------+---------------------------|\n>     | Switch                    | git switch existing    | git switch existing       |\n>     | Error                     | git switch nonexisting | <no change (errors)>      |\n>     | Switch with --merge       | git switch -m branch   | git switch --merge branch |\n>     | Create                    | git switch -c new      | git switch -n new         |\n>     | Create from existing      | N/A                    | git switch -c new [<old>] |\n>     | Move & switch to existing | N/A                    | git switch -m new [<old>] |\n>     |---------------------------+------------------------+---------------------------|\n\nI'm in favor of this too.\n\n> In its current state I find \"git switch\" to be unusable. That sounds\n> like dramatic hyperbole, but I'm serious.\n\nI concur.\n\nI've tried to use it multiple times, and I always come back to using git\nbranch / git checkout.\n\n-- \nFelipe Contreras"},{"id":"423701","messageId":"6092db4384938_1d2452084a@natae.notmuch","threadId":"55617","inReplyTo":"nycvar.QRO.7.76.6.2105051554250.50@tvgsbejvaqbjf.bet","subject":"Re: git switch/restore, still experimental?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-05T17:52:03Z","receivedAt":"2021-05-05T18:04:11Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Johannes Schindelin wrote:\n> Which leaves us with two hard choices regarding switch/restore, none of\n> them really being comfortable:\n> \n> - we scrap switch/restore because their usability is not really all that\n>   improved relative to `git checkout`.\n> \n> - we leave switch/restore as-are (because by now, changing the options or\n>   the design would be almost certainly disruptive to users who already\n>   tried to adopt the new commands, I being one of those users).\n\nThere's another option:\n\n - we revamp completely switch/restore (because any users relying on\n   them by now were warned they shouldn't assume these commands to stay\n   as they are).\n\n> I say that neither of them is a really splendid choice because the\n> original goal is not only not accomplished, but I would say it is even\n> harder now than it was when we accepted switch/restore into an official\n> release, because of that experience with switch/restore. We simply do not\n> have the right expertise on this list, and therefore anything we do will\n> always have that \"UX designed by an engineer\" feel.\n\nI disagree. Engineers can create a good UI, especially after trying\nfor a while failed attempts.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"423714","messageId":"87y2ct56dh.fsf@osv.gnss.ru","threadId":"55617","inReplyTo":"6092da0ccf4e9_1d24520833@natae.notmuch","subject":"Re: git switch/restore, still experimental?","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-05-05T19:26:50Z","receivedAt":"2021-05-05T19:26:59Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> Ævar Arnfjörð Bjarmason wrote:\n>> In summary, I think it should be changed to act like this:\n>>     \n>>     |---------------------------+------------------------+---------------------------|\n>>     | What | Now | New |\n>>     |---------------------------+------------------------+---------------------------|\n>>     | Switch | git switch existing | git switch existing |\n>>     | Error | git switch nonexisting | <no change (errors)> |\n>>     | Switch with --merge | git switch -m branch | git switch\n>>     | --merge branch |\n>>     | Create | git switch -c new | git switch -n new |\n>>     | Create from existing | N/A | git switch -c new [<old>] |\n>>     | Move & switch to existing | N/A | git switch -m new [<old>] |\n>>     |---------------------------+------------------------+---------------------------|\n>\n> I'm in favor of this too.\n>\n>> In its current state I find \"git switch\" to be unusable. That sounds\n>> like dramatic hyperbole, but I'm serious.\n>\n> I concur.\n>\n> I've tried to use it multiple times, and I always come back to using git\n> branch / git checkout.\n\nI didn't look at these commands till recently, and what I immediately\nnoticed is very unclear manual pages. I didn't read entire pages, but\nDESCRIPTIONS sections and some options I did check. I think that even if\nthese commands are to be considered stable by now, the manual pages\nthemselves need to be heavily revised before removing the EXPERIMENTAL\nlabel.\n\nIt'll be worse if unclear manual is just a symptom of unclear design\nthough.\n\nThanks,\n-- Sergey Organov\n"},{"id":"423716","messageId":"87sg3155dt.fsf@osv.gnss.ru","threadId":"55617","inReplyTo":"877dkdwgfe.fsf@evledraar.gmail.com","subject":"Re: git switch/restore, still experimental?","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-05-05T19:48:14Z","receivedAt":"2021-05-05T19:48:18Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> On Tue, May 04 2021, Elijah Newren wrote:\n>\n>> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com> wrote:\n>>>\n>>> hi,\n>>>\n>>> the \"git switch\" and \"git restore\" commands were released two years\n>>> ago, but the manpage still says \"THIS COMMAND IS EXPERIMENTAL. THE\n>>> BEHAVIOR MAY CHANGE.\".\n>>>\n>>> i'd love to use them, but this warning gives me pause, perhaps i\n>>> should wait until it stops being experimental, i worry that it might\n>>> change in behavior unexpectedly and cause problems for me.\n>>>\n>>> considering that they were released two years ago, could the\n>>> experimental-warning be removed now?\n>>>\n>>> thanks,\n>>> gabor\n>>\n>> This probably makes sense.  The author of switch and restore isn't\n>> involved in the git project anymore.  He decided to work on other\n>> things, which was and is a big loss for us.  I think others (myself\n>> included) didn't know all the things that might have been in Duy's\n>> head that he wanted to verify were working well before marking this as\n>> good, but these two commands have generally been very well received\n>> and it has been a few years.  Personally, I'm not aware of anything\n>> that we'd need or want to change with these commands.\n>\n> I am.\n>\n\n[...]\n\n> And:\n>\n>    # Moves a branch (or -M for --force)\n>    git branch -m old new\n>\n> That last one we can't have either because \"switch\" squats on \"-m\" for\n> \"--merge\", which I daresay is a much more obscure use-case not deserving\n> of a short option than \"rename and switch to\".\n\nIsn't --merge a different (and inferior) way to achieve what we already\nhave elsewhere with --autostash? Does it make sense to get rid of --merge\nhere in favor of --autostash?\n\nThanks,\n-- Sergey Organov\n"},{"id":"423727","messageId":"xmqqzgx81x2q.fsf@gitster.g","threadId":"55617","inReplyTo":"00af01d741ba$b916a330$2b43e990$@nexbridge.com","subject":"Re: git switch/restore, still experimental?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-06T01:15:57Z","receivedAt":"2021-05-06T01:16:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Randall S. Becker\" <rsbecker@nexbridge.com> writes:\n\n>>Which leaves us with two hard choices regarding switch/restore, none of them\n>>really being comfortable:\n>>\n>>- we scrap switch/restore because their usability is not really all that\n>>  improved relative to `git checkout`.\n>\n> Please do not do that. Switch/restore is much easier to understand\n> for new users. The semantics are also more consistent with what\n> others have done with git over the years anyway (EGit as an\n> example). I have users who have transitioned because the commands\n> make sense. They have not hit any missing bits in their workflows.\n>\n>>- we leave switch/restore as-are (because by now, changing the options or\n>>  the design would be almost certainly disruptive to users who already\n>>  tried to adopt the new commands, I being one of those users).\n>\n> I think we should work on the commands to cover between them\n> (well... and reset) to functionally cover what checkout\n> does. Leaving them as-is, I think is not a viable option. People\n> do know these are experimental and not to use in scripts - we can\n> hope anyway.\n\nYeah, I tend to agree with you that the third-choice to improve\nswitch/restore before we can confidently say they are no longer\n\"experimental\" would be much nicer than giving up on them too early.\n"},{"id":"423730","messageId":"xmqqk0oc1vzj.fsf@gitster.g","threadId":"55617","inReplyTo":"87sg3155dt.fsf@osv.gnss.ru","subject":"Re: git switch/restore, still experimental?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-06T01:39:28Z","receivedAt":"2021-05-06T01:39:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergey Organov <sorganov@gmail.com> writes:\n\n> Isn't --merge a different (and inferior) way to achieve what we already\n> have elsewhere with --autostash? Does it make sense to get rid of --merge\n> here in favor of --autostash?\n\nNot really.\n\nThe \"--autostash\" might appear to be applicable to cases that can\ninduce larger conflict, but once the diversion gets larger than what\none comfortably can deal with \"checkout -m\", the user is better off\nto work by forking a branch there and create a WIP commit, than deal\nwith the stash.  So if anything, I'd rather get rid of \"--autostash\"\nthan \"-m\", to help users get in a better work habit.\n\n\n"},{"id":"423733","messageId":"xmqq35v01ua3.fsf@gitster.g","threadId":"55617","inReplyTo":"877dkdwgfe.fsf@evledraar.gmail.com","subject":"Re: git switch/restore, still experimental?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-06T02:16:20Z","receivedAt":"2021-05-06T02:16:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> I mean, I see why. You don't want a typo of \"master\" as \"maaster\" to\n> create a new \"maaster\" branch, so really that's out. But it really\n> should be:\n>\n>     # -n or -N for --new / --new --force (the latter just in case of a\n>     # race, and just for consistency)\n>     git switch -n doesnotexist\n\nI do not see why --new is better than --create; we did choose not to\nreuse --branch from \"checkout\" and I remember that was a deliberate\ndecision (i.e. once split into \"switch\" and \"restore\", \"switch\"\nbecomes only about branches, so unlike in the context of \"checkout\",\nin the context of \"switch\", the word \"branch\" adds a lot less value,\nand certainly does not signal we are creating a branch and switching\nto it).\n\nIt would have been a stronger argument to favor --new if we had \"git\nbranch --new <branchname>\", but that is not the case.\n\n"},{"id":"423763","messageId":"87pmy4uqhz.fsf@evledraar.gmail.com","threadId":"55617","inReplyTo":"xmqq35v01ua3.fsf@gitster.g","subject":"Re: git switch/restore, still experimental?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-06T10:02:28Z","receivedAt":"2021-05-06T10:05:18Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, May 06 2021, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> I mean, I see why. You don't want a typo of \"master\" as \"maaster\" to\n>> create a new \"maaster\" branch, so really that's out. But it really\n>> should be:\n>>\n>>     # -n or -N for --new / --new --force (the latter just in case of a\n>>     # race, and just for consistency)\n>>     git switch -n doesnotexist\n>\n> I do not see why --new is better than --create; we did choose not to\n> reuse --branch from \"checkout\" and I remember that was a deliberate\n> decision (i.e. once split into \"switch\" and \"restore\", \"switch\"\n> becomes only about branches, so unlike in the context of \"checkout\",\n> in the context of \"switch\", the word \"branch\" adds a lot less value,\n> and certainly does not signal we are creating a branch and switching\n> to it).\n\nI don't think --new is better than --create when considered in\nisolation. I happen to think --create is better.\n\nWhat I'm arguing is that we should be aiming for some consistency in the\ncommand-set. In this case the relatively small change of\ns/--create/--new/ server so make the rest consistent. I.e. the branch\nand switch commands can mirror each other in the ways that matter for\nthese common operations of create/copy/move.\n\n> It would have been a stronger argument to favor --new if we had \"git\n> branch --new <branchname>\", but that is not the case.\n\nThe argument is that switch's experimental design squats on 2x other\noptions, so changing -c to -n so we can make -c and -m do the same thing\nis better.\n"},{"id":"423764","messageId":"87mtt8uqec.fsf@evledraar.gmail.com","threadId":"55617","inReplyTo":"87sg3155dt.fsf@osv.gnss.ru","subject":"Re: git switch/restore, still experimental?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-06T10:05:23Z","receivedAt":"2021-05-06T10:07:28Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, May 05 2021, Sergey Organov wrote:\n\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> On Tue, May 04 2021, Elijah Newren wrote:\n>>\n>>> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com> wrote:\n>>>>\n>>>> hi,\n>>>>\n>>>> the \"git switch\" and \"git restore\" commands were released two years\n>>>> ago, but the manpage still says \"THIS COMMAND IS EXPERIMENTAL. THE\n>>>> BEHAVIOR MAY CHANGE.\".\n>>>>\n>>>> i'd love to use them, but this warning gives me pause, perhaps i\n>>>> should wait until it stops being experimental, i worry that it might\n>>>> change in behavior unexpectedly and cause problems for me.\n>>>>\n>>>> considering that they were released two years ago, could the\n>>>> experimental-warning be removed now?\n>>>>\n>>>> thanks,\n>>>> gabor\n>>>\n>>> This probably makes sense.  The author of switch and restore isn't\n>>> involved in the git project anymore.  He decided to work on other\n>>> things, which was and is a big loss for us.  I think others (myself\n>>> included) didn't know all the things that might have been in Duy's\n>>> head that he wanted to verify were working well before marking this as\n>>> good, but these two commands have generally been very well received\n>>> and it has been a few years.  Personally, I'm not aware of anything\n>>> that we'd need or want to change with these commands.\n>>\n>> I am.\n>>\n>\n> [...]\n>\n>> And:\n>>\n>>    # Moves a branch (or -M for --force)\n>>    git branch -m old new\n>>\n>> That last one we can't have either because \"switch\" squats on \"-m\" for\n>> \"--merge\", which I daresay is a much more obscure use-case not deserving\n>> of a short option than \"rename and switch to\".\n>\n> Isn't --merge a different (and inferior) way to achieve what we already\n> have elsewhere with --autostash? Does it make sense to get rid of --merge\n> here in favor of --autostash?\n\nProbably, I haven't used the --merge option ever I think. Switching with\ndirty worktrees isn't really how I work.\n\nBut to the extent that I've ever tried / run into errors with that I'd\nthink that an option like --merge or --autostash is mostly a result of\nus being overzealous about \"is_dirty() && die()\" checks. E.g. rebase (at\nleast a while ago, still) would refuse to rebase with a dirty tree, even\nthough the path in question had nothing to do with paths that would be\ntouched by the rebase.\n\nI suspect that much of the need for these sorts of options would go away\nwith those checks being smarter, but it's separate from the \"should we\nsquat on -m\" discussion...\n"},{"id":"423768","messageId":"6093cc63a4e81_325720840@natae.notmuch","threadId":"55617","inReplyTo":"xmqq35v01ua3.fsf@gitster.g","subject":"Re: git switch/restore, still experimental?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-06T11:00:51Z","receivedAt":"2021-05-06T11:01:11Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n> \n> > I mean, I see why. You don't want a typo of \"master\" as \"maaster\" to\n> > create a new \"maaster\" branch, so really that's out. But it really\n> > should be:\n> >\n> >     # -n or -N for --new / --new --force (the latter just in case of a\n> >     # race, and just for consistency)\n> >     git switch -n doesnotexist\n> \n> I do not see why --new is better than --create;\n\nI do. Different languages equal different minds.\n\nNew in this context is an adjetive: it is a modifier of a noun, in this\ncase, a branch.\n\nCreate is a verb; it's an action.\n\nLinguistically speaking they could not be more different.\n\n\nYou don't do two verbs at a time. Either you sleep, or you eat, but you\ndon't do both. Similarly you don't switch and create. Doesn't make\nsense.\n\nIf you use natural language:\n\n  1. Git, switch to a new branch\n\n  2. Git, switch, create, branch\n\nOne of these simply flows, the other is complete gibberish. I think\nanyone familiar with English can identify which is which.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"423777","messageId":"87o8doue98.fsf@osv.gnss.ru","threadId":"55617","inReplyTo":"87mtt8uqec.fsf@evledraar.gmail.com","subject":"Re: git switch/restore, still experimental?","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-05-06T14:29:39Z","receivedAt":"2021-05-06T14:29:46Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> On Wed, May 05 2021, Sergey Organov wrote:\n>\n>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>>\n>>> On Tue, May 04 2021, Elijah Newren wrote:\n>>>\n>>>> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com> wrote:\n>>>>>\n>>>>> hi,\n>>>>>\n>>>>> the \"git switch\" and \"git restore\" commands were released two years\n>>>>> ago, but the manpage still says \"THIS COMMAND IS EXPERIMENTAL. THE\n>>>>> BEHAVIOR MAY CHANGE.\".\n>>>>>\n>>>>> i'd love to use them, but this warning gives me pause, perhaps i\n>>>>> should wait until it stops being experimental, i worry that it might\n>>>>> change in behavior unexpectedly and cause problems for me.\n>>>>>\n>>>>> considering that they were released two years ago, could the\n>>>>> experimental-warning be removed now?\n>>>>>\n>>>>> thanks,\n>>>>> gabor\n>>>>\n>>>> This probably makes sense.  The author of switch and restore isn't\n>>>> involved in the git project anymore.  He decided to work on other\n>>>> things, which was and is a big loss for us.  I think others (myself\n>>>> included) didn't know all the things that might have been in Duy's\n>>>> head that he wanted to verify were working well before marking this as\n>>>> good, but these two commands have generally been very well received\n>>>> and it has been a few years.  Personally, I'm not aware of anything\n>>>> that we'd need or want to change with these commands.\n>>>\n>>> I am.\n>>>\n>>\n>> [...]\n>>\n>>> And:\n>>>\n>>>    # Moves a branch (or -M for --force)\n>>>    git branch -m old new\n>>>\n>>> That last one we can't have either because \"switch\" squats on \"-m\" for\n>>> \"--merge\", which I daresay is a much more obscure use-case not deserving\n>>> of a short option than \"rename and switch to\".\n>>\n>> Isn't --merge a different (and inferior) way to achieve what we already\n>> have elsewhere with --autostash? Does it make sense to get rid of --merge\n>> here in favor of --autostash?\n>\n> Probably, I haven't used the --merge option ever I think. Switching with\n> dirty worktrees isn't really how I work.\n>\n> But to the extent that I've ever tried / run into errors with that I'd\n> think that an option like --merge or --autostash is mostly a result of\n> us being overzealous about \"is_dirty() && die()\" checks. E.g. rebase (at\n> least a while ago, still) would refuse to rebase with a dirty tree, even\n> though the path in question had nothing to do with paths that would be\n> touched by the rebase.\n\nUnfortunately, this will never solve the problem entirely. Global\nautostash mode probably will, more chances if stash will save/restore\nexact state of everything when applied to the original base.\n\n>\n> I suspect that much of the need for these sorts of options would go away\n> with those checks being smarter, but it's separate from the \"should we\n> squat on -m\" discussion...\n\nIt is not entirely separate. If --merge goes away, there will be no\n\"squat on -m\" anymore.\n\nPersonally, I'd just turn on global autostash mode if it were available,\nand forget about both --merge and --autostash, for the better.\n\nThanks,\n-- Sergey Organov\n"},{"id":"423787","messageId":"87k0obvqi0.fsf@osv.gnss.ru","threadId":"55617","inReplyTo":"xmqqk0oc1vzj.fsf@gitster.g","subject":"Re: git switch/restore, still experimental?","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-05-06T15:19:51Z","receivedAt":"2021-05-06T15:19:58Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Sergey Organov <sorganov@gmail.com> writes:\n>\n>> Isn't --merge a different (and inferior) way to achieve what we already\n>> have elsewhere with --autostash? Does it make sense to get rid of --merge\n>> here in favor of --autostash?\n>\n> Not really.\n\nI tend to disagree. \n\n> The \"--autostash\" might appear to be applicable to cases that can\n> induce larger conflict,\n\nTo me (auto)stash is not about amount of possible conflicts, and even\nnot about conflicts at all, but rather about data safety. (Auto)stash is\nreversible: just get to original branch, apply the stash, and you are\nbasically back where you was.\n\nBesides, --autostash shouldn't necessarily even imply --autorestore. I\ncan easily imagine a mode when --autorestore is fired only when one\nreturns to the branch where --autostash has been performed, leaving to\nthe user the responsibility of applying the stash to the new branch, if\nshe really needs it.\n\nOTOH, --merge sounds more like infamous \"cvs update\". Keep fingers\ncrossed (or rather do a backup) and push the button, – Git will do its\nbest not to clobber your content, but all bets are off.\n\n> but once the diversion gets larger than what one comfortably can deal\n> with \"checkout -m\",\n\nThe problem is that I suspect there is no such margin. I'm simply\nuncomfortable with -m. It doesn't sound safe to me no matter what. I'll\nrather stash manually than use -m.\n\n> the user is better off to work by forking a branch there and create a\n> WIP commit, than deal with the stash.\n\nWhy? This looks like unjustified complication. All this is temporary\nenough for the stash proper, – one just forgets about it immediately\nmost of times, as things typically go rather smooth anyway.\n\n> So if anything, I'd rather get rid of \"--autostash\" than \"-m\", to help\n> users get in a better work habit.\n\nI have as much as 3 points to oppose to this:\n\n1. Who decides which work habit is better? At the same time, data safety\nand recovery are unprejudiced goals to be aimed at.\n\n2. Unlike --merge, --autostash is universal. Whatever job is to be done,\nget your changes to a safe place before continuing, to be able get them\nback later. It'd be excellent if we had global autostash mode support,\nespecially if stash were capable to save/restore entire state of\neverything. Sounds like \"Undo\" in text editors, or like automatic backup\nbefore OS update.\n\n3. Dunno about --merge, but I'm sure --autostash came from real life. I\nsee it all the time how users do \"git stash; git pull; git stash pop\"\nsequence. It's just natural, and if it suits them, who are we to decide\nwhat's \"better\" for them? I believe Git should continue to provide\nconvenient tools that help to get the job done, rather than trying to\nfight \"improper\" habits and/or workflows.\n\nOverall, to me --autostash is clear winner :)\n\nThat said, I somehow feel this has been already discussed to death when\n--autostash was introduced.\n\nThanks,\n-- Sergey Organov\n"},{"id":"423790","messageId":"87h7jfvq09.fsf@evledraar.gmail.com","threadId":"55617","inReplyTo":"6093cc63a4e81_325720840@natae.notmuch","subject":"Re: git switch/restore, still experimental?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-06T15:26:37Z","receivedAt":"2021-05-06T15:30:37Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, May 06 2021, Felipe Contreras wrote:\n\n> Junio C Hamano wrote:\n>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>> \n>> > I mean, I see why. You don't want a typo of \"master\" as \"maaster\" to\n>> > create a new \"maaster\" branch, so really that's out. But it really\n>> > should be:\n>> >\n>> >     # -n or -N for --new / --new --force (the latter just in case of a\n>> >     # race, and just for consistency)\n>> >     git switch -n doesnotexist\n>> \n>> I do not see why --new is better than --create;\n>\n> I do. Different languages equal different minds.\n>\n> New in this context is an adjetive: it is a modifier of a noun, in this\n> case, a branch.\n>\n> Create is a verb; it's an action.\n>\n> Linguistically speaking they could not be more different.\n>\n>\n> You don't do two verbs at a time. Either you sleep, or you eat, but you\n> don't do both. Similarly you don't switch and create. Doesn't make\n> sense.\n>\n> If you use natural language:\n>\n>   1. Git, switch to a new branch\n>\n>   2. Git, switch, create, branch\n>\n> One of these simply flows, the other is complete gibberish. I think\n> anyone familiar with English can identify which is which.\n\nWell, there's \"Git, create a new branch and switch to it\"\n\nAlso, there's the verb \"make\" in common use in git's command set\ne.g. git-mktag, git-mktree, as well as mkdir(1), mkfifo(1) etc.\n\nPerhaps we'd be better off with a git-mkbranch in this case & leave \"git\nbranch\" as an interrogation/change command.\n\nIn any case, unless we're talking about rewamping git's entire command\nset (e.g. having a git-newtree or whatever) I'd like to think that it's\nmore productive to focus on making the commands/switches we have\ninternally consistent when possible, which is what I'm advocating in the\nE-Mail that started this sub-thread.\n"},{"id":"423825","messageId":"609465b55e183_577f20852@natae.notmuch","threadId":"55617","inReplyTo":"87h7jfvq09.fsf@evledraar.gmail.com","subject":"Re: git switch/restore, still experimental?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-06T21:55:01Z","receivedAt":"2021-05-06T21:55:11Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Thu, May 06 2021, Felipe Contreras wrote:\n\n> > If you use natural language:\n> >\n> >   1. Git, switch to a new branch\n> >\n> >   2. Git, switch, create, branch\n> >\n> > One of these simply flows, the other is complete gibberish. I think\n> > anyone familiar with English can identify which is which.\n> \n> Well, there's \"Git, create a new branch and switch to it\"\n\nWhich command is that?\n\n  git create branch --checkout?\n\nI'm following the order of the words from left to right.\n\n> Also, there's the verb \"make\" in common use in git's command set\n> e.g. git-mktag, git-mktree, as well as mkdir(1), mkfifo(1) etc.\n\nSure, although I wouldn't consider them main commands. I for one never\nuse them.\n\n> In any case, unless we're talking about rewamping git's entire command\n> set (e.g. having a git-newtree or whatever) I'd like to think that it's\n> more productive to focus on making the commands/switches we have\n> internally consistent when possible, which is what I'm advocating in the\n> E-Mail that started this sub-thread.\n\nBut we are talking about a new command, it is precisely at this point we\nneed to think about what could have been if mistakes of the past had not\nhappened.\n\nWe should not repeat past mistakes without a very good reason.\n\nI don't think we should seek consistency for consistency's sake. Sure,\nconsistency is good, but it's only one of many considerations.\n\nIn this case however we have a rare occasion in which both consistency and\nnatural language meet, we should not squander it.\n\nIn fact, to be even more consistent we could add a -n option to git\nbranch, which would be reduntant but more explicit, like --list.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"424018","messageId":"8735uuvois.fsf@evledraar.gmail.com","threadId":"55617","inReplyTo":"609465b55e183_577f20852@natae.notmuch","subject":"Re: git switch/restore, still experimental?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-10T10:58:16Z","receivedAt":"2021-05-10T11:20:23Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, May 06 2021, Felipe Contreras wrote:\n\n> Ævar Arnfjörð Bjarmason wrote:\n>> On Thu, May 06 2021, Felipe Contreras wrote:\n\nFirst of all, I think we're in rather violent agreement about the real\nmatter at hand here, and are at best talking about the design of the\nkeychain for the bikeshed...\n\n>> > If you use natural language:\n>> >\n>> >   1. Git, switch to a new branch\n>> >\n>> >   2. Git, switch, create, branch\n>> >\n>> > One of these simply flows, the other is complete gibberish. I think\n>> > anyone familiar with English can identify which is which.\n>> \n>> Well, there's \"Git, create a new branch and switch to it\"\n>\n> Which command is that?\n>\n>   git create branch --checkout?\n>\n> I'm following the order of the words from left to right.\n\nI'm just pointing out that git in general and certainly not the *nix\ntradition it follows tries to make commands readable in anything like\nEnglish sentence order. If you attempt to read \"log\", \"status\", \"rebase\"\netc. commands like that you'll at best end up sounding somewhat like\nYoda.\n\n>> Also, there's the verb \"make\" in common use in git's command set\n>> e.g. git-mktag, git-mktree, as well as mkdir(1), mkfifo(1) etc.\n>\n> Sure, although I wouldn't consider them main commands. I for one never\n> use them.\n>\n>> In any case, unless we're talking about rewamping git's entire command\n>> set (e.g. having a git-newtree or whatever) I'd like to think that it's\n>> more productive to focus on making the commands/switches we have\n>> internally consistent when possible, which is what I'm advocating in the\n>> E-Mail that started this sub-thread.\n>\n> But we are talking about a new command, it is precisely at this point we\n> need to think about what could have been if mistakes of the past had not\n> happened.\n>\n> We should not repeat past mistakes without a very good reason.\n>\n> I don't think we should seek consistency for consistency's sake. Sure,\n> consistency is good, but it's only one of many considerations.\n>\n> In this case however we have a rare occasion in which both consistency and\n> natural language meet, we should not squander it.\n>\n> In fact, to be even more consistent we could add a -n option to git\n> branch, which would be reduntant but more explicit, like --list.\n\nIndeed, I agree with all of that. I.e. we should move to \"switch\" to\n\"-n\" instead of \"-c\" etc., and add a \"-n\" to \"branch\" for\nconsistency. After all that's my upthread proposal...\n\nI just don't think it's worth trying to make the argv readable as a\nsentence, even if we had no backwards compatibility to worry about.\n"},{"id":"424020","messageId":"87zgx2u9pu.fsf@evledraar.gmail.com","threadId":"55617","inReplyTo":"87pmy4uqhz.fsf@evledraar.gmail.com","subject":"Re: git switch/restore, still experimental?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-10T11:04:48Z","receivedAt":"2021-05-10T11:20:23Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, May 06 2021, Ævar Arnfjörð Bjarmason wrote:\n\n> On Thu, May 06 2021, Junio C Hamano wrote:\n\n*Poke*\n\n>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>>\n>>> I mean, I see why. You don't want a typo of \"master\" as \"maaster\" to\n>>> create a new \"maaster\" branch, so really that's out. But it really\n>>> should be:\n>>>\n>>>     # -n or -N for --new / --new --force (the latter just in case of a\n>>>     # race, and just for consistency)\n>>>     git switch -n doesnotexist\n>>\n>> I do not see why --new is better than --create; we did choose not to\n>> reuse --branch from \"checkout\" and I remember that was a deliberate\n>> decision (i.e. once split into \"switch\" and \"restore\", \"switch\"\n>> becomes only about branches, so unlike in the context of \"checkout\",\n>> in the context of \"switch\", the word \"branch\" adds a lot less value,\n>> and certainly does not signal we are creating a branch and switching\n>> to it).\n>\n> I don't think --new is better than --create when considered in\n> isolation. I happen to think --create is better.\n>\n> What I'm arguing is that we should be aiming for some consistency in the\n> command-set. In this case the relatively small change of\n> s/--create/--new/ server so make the rest consistent. I.e. the branch\n> and switch commands can mirror each other in the ways that matter for\n> these common operations of create/copy/move.\n>\n>> It would have been a stronger argument to favor --new if we had \"git\n>> branch --new <branchname>\", but that is not the case.\n>\n> The argument is that switch's experimental design squats on 2x other\n> options, so changing -c to -n so we can make -c and -m do the same thing\n> is better.\n\nWhatever the merit of the argument I'm putting forward here, it would be\nuseful to get some idea of whether you'd be categorically opposed to\nchanging the interface of switch/restore in breaking ways even though\nthey've been marked as \"THIS COMMAND IS EXPERIMENTAL\".\n\nOf course any series to implement what I suggested in\n<877dkdwgfe.fsf@evledraar.gmail.com> would need to stand on its own\nmerits.\n\nI'm not planning on working on that since I expect the response will be\nat best \"neat, but that ship has sailed\", but if that's not the case...\n"},{"id":"424066","messageId":"xmqqtunaphoz.fsf@gitster.g","threadId":"55617","inReplyTo":"87zgx2u9pu.fsf@evledraar.gmail.com","subject":"Re: git switch/restore, still experimental?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-10T18:27:56Z","receivedAt":"2021-05-10T18:28:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n>>> It would have been a stronger argument to favor --new if we had \"git\n>>> branch --new <branchname>\", but that is not the case.\n>>\n>> The argument is that switch's experimental design squats on 2x other\n>> options, so changing -c to -n so we can make -c and -m do the same thing\n>> is better.\n>\n> Whatever the merit of the argument I'm putting forward here, it would be\n> useful to get some idea of whether you'd be categorically opposed to\n> changing the interface of switch/restore in breaking ways even though\n> they've been marked as \"THIS COMMAND IS EXPERIMENTAL\".\n>\n> Of course any series to implement what I suggested in\n> <877dkdwgfe.fsf@evledraar.gmail.com> would need to stand on its own\n> merits.\n>\n> I'm not planning on working on that since I expect the response will be\n> at best \"neat, but that ship has sailed\", but if that's not the case...\n\ncf. <xmqqzgx81x2q.fsf@gitster.g>\n\n\"Randall S. Becker\" <rsbecker@nexbridge.com> writes:\n\n>>Which leaves us with two hard choices regarding switch/restore, none of them\n>>really being comfortable:\n>>\n>>- we scrap switch/restore because their usability is not really all that\n>>  improved relative to `git checkout`.\n>\n> Please do not do that. Switch/restore is much easier to understand\n> for new users. The semantics are also more consistent with what\n> others have done with git over the years anyway (EGit as an\n> example). I have users who have transitioned because the commands\n> make sense. They have not hit any missing bits in their workflows.\n>\n>>- we leave switch/restore as-are (because by now, changing the options or\n>>  the design would be almost certainly disruptive to users who already\n>>  tried to adopt the new commands, I being one of those users).\n>\n> I think we should work on the commands to cover between them\n> (well... and reset) to functionally cover what checkout\n> does. Leaving them as-is, I think is not a viable option. People\n> do know these are experimental and not to use in scripts - we can\n> hope anyway.\n\nYeah, I tend to agree with you that the third-choice to improve\nswitch/restore before we can confidently say they are no longer\n\"experimental\" would be much nicer than giving up on them too early.\n"},{"id":"424116","messageId":"609a2f0c7353b_5d5d3208a7@natae.notmuch","threadId":"55617","inReplyTo":"8735uuvois.fsf@evledraar.gmail.com","subject":"Re: git switch/restore, still experimental?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-11T07:15:24Z","receivedAt":"2021-05-11T07:15:30Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Thu, May 06 2021, Felipe Contreras wrote:\n> \n> First of all, I think we're in rather violent agreement about the real\n> matter at hand here, and are at best talking about the design of the\n> keychain for the bikeshed...\n\nIndeed. The design of the hypothetical keychain for future bikesheds.\n\n> > Which command is that?\n> >\n> >   git create branch --checkout?\n> >\n> > I'm following the order of the words from left to right.\n> \n> I'm just pointing out that git in general and certainly not the *nix\n> tradition it follows tries to make commands readable in anything like\n> English sentence order. If you attempt to read \"log\", \"status\", \"rebase\"\n> etc. commands like that you'll at best end up sounding somewhat like\n> Yoda.\n\nRight, but git is infamous for having a UI that leaves a lot to be\ndesired. I'm less concerned about the status quo of git's UI than I am\nof what could be.\n\nInertia is something that just can't be ignored on commands that people\nhave been using for 15 years.\n\nMy point is that new commands should not follow the inertia of old\ncommands, especially when we know that historically the UI is the thing\nthat needs more improvements. In fact, we should do the *opposite*. It's\nthe less-than-stellar UI that created the need for switch/restore in the\nfirst place.\n\n> > In this case however we have a rare occasion in which both consistency and\n> > natural language meet, we should not squander it.\n> >\n> > In fact, to be even more consistent we could add a -n option to git\n> > branch, which would be reduntant but more explicit, like --list.\n> \n> Indeed, I agree with all of that. I.e. we should move to \"switch\" to\n> \"-n\" instead of \"-c\" etc., and add a \"-n\" to \"branch\" for\n> consistency. After all that's my upthread proposal...\n> \n> I just don't think it's worth trying to make the argv readable as a\n> sentence, even if we had no backwards compatibility to worry about.\n\nWell, we would need to look at particular examples to see if the\ncounter-examples make more sene or not.\n\nEither way my contention is that it doesn't hurt.\n\nI will take a look at switch/restore and see if a linguist approach\ngives more low-hanging fruit.\n\nFortunately none of that matters for your particular proposal which is\njust good.\n\nCheers.\n\n-- \nFelipe Contreras"}]}