{"thread":{"id":"59925","subject":"git-switch history and checkout compatibility","startedAt":"2023-06-28T13:03:57Z","lastAt":"2023-08-01T18:29:11Z","messageCount":4,"participants":["Namikaze Minato","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"478956","messageId":"CACmJb3xWh+0BR_V6sxfMK7iMSdWfvY9d2rjt1hnZhFw70zWweA@mail.gmail.com","threadId":"59925","inReplyTo":"CACmJb3yoHagaU1wb4qRT-nZV4Wptao8boaUXCAYrFxfrxcmUYg@mail.gmail.com","subject":"git-switch history and checkout compatibility","fromName":"Namikaze Minato","fromEmail":"lloydsensei+git@gmail.com","sentAt":"2023-06-28T13:03:22Z","receivedAt":"2023-06-28T13:03:57Z","isPatch":false,"sender":{"key":"lloydsensei+git@gmail.com","avatar":null},"body":"Hello,\n\nI have been waiting for people to report this but it never came so I'm doing it:\n\nI have trouble with getting used to git-switch instead of\ngit-checkout, but have even more trouble to get people to adopt it.\n\nPlease consider the two following git-switch statements:\n\ngit switch remote/branch # fatal: a branch is expected, got remote\nbranch 'remote/branch'\n#and\ngit switch -d remote/branch\ngit switch master\ngit switch - # fatal: a branch is expected, got commit 'commit_id_here'\n\nBoth as retro-compatibility with checkout and for user-friendliness, I\nwould expect both to work.\nMaybe a setting checkout.autoDetach could control such behavior if the\ncurrent implementation should be kept?\n\nWhat do you think?\n\nKind regards,\nMinato\n"},{"id":"478965","messageId":"xmqqa5wjee25.fsf@gitster.g","threadId":"59925","inReplyTo":"CACmJb3xWh+0BR_V6sxfMK7iMSdWfvY9d2rjt1hnZhFw70zWweA@mail.gmail.com","subject":"Re: git-switch history and checkout compatibility","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-06-28T16:39:46Z","receivedAt":"2023-06-28T16:40:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Namikaze Minato writes:\n\n> I have trouble with getting used to git-switch instead of\n> git-checkout, but have even more trouble to get people to adopt\n> it.\n>\n> Please consider the two following git-switch statements:\n>\n> git switch remote/branch # fatal: a branch is expected, got remote\n> branch 'remote/branch'\n> #and\n> git switch -d remote/branch\n> git switch master\n> git switch - # fatal: a branch is expected, got commit 'commit_id_here'\n>\n> Both as retro-compatibility with checkout and for user-friendliness, I\n> would expect both to work.\n\nI wasn't among the primary advocates to add \"switch/restore\" pair\nfor those people who felt \"checkout\" was overloaded, and I may be\nmisremembering why they decided to deviate from what \"checkout\"\n(one that checks out a branch, not the one that checks out paths)\ndid in these two cases. Having said that ...\n\n * I suspect that requiring an explicit \"--detach\" is deliberate, as\n they were trying to make \"newbie friendlier\" version of checkout.\n\n * I am on the fence about the latter one. While I think it is a\n bug if \"switch -\" and \"switch @{-1}\" did not work exactly like\n \"checkout @{-1}\", combined with the previous point of requiring\n to be explicit when detaching HEAD, \"switch -\" that tries to go\n back to a detached state may be justifiable---it stops you in\n order to avoid accidental detaching of HEAD.\n\n> Maybe a setting checkout.autoDetach could control such behavior if the\n> current implementation should be kept?\n>\n> What do you think?\n\nPersonally, I think those who are familiar with and expert enough on\nGit and do not feel uneasy working on detached HEAD can and should\njust use \"checkout\" not \"switch/restore\", but that may be just me.\n\nThanks.\n"},{"id":"480054","messageId":"CACmJb3wTsWdqDGrkYC0p+eB-XYBotVcFAKcXJF3ftYdiiRvEdw@mail.gmail.com","threadId":"59925","inReplyTo":"xmqqa5wjee25.fsf@gitster.g","subject":"Re: git-switch history and checkout compatibility","fromName":"Namikaze Minato","fromEmail":"lloydsensei+git@gmail.com","sentAt":"2023-08-01T17:23:20Z","receivedAt":"2023-08-01T17:24:26Z","isPatch":false,"sender":{"key":"lloydsensei+git@gmail.com","avatar":null},"body":"On Wed, 28 Jun 2023 at 18:39, Junio C Hamano wrote:\n> * I suspect that requiring an explicit \"--detach\" is deliberate, as\n> they were trying to make \"newbie friendlier\" version of checkout.\nYes, I also believe this is deliberate.\nI do not think however it makes it newbie-friendly.\nAs I said, on the contrary, I am having a hard time to get newbies to\nstart using switch precisely because it behaves differently from\ncheckout.\n\n> * I am on the fence about the latter one. While I think it is a\n> bug if \"switch -\" and \"switch @{-1}\" did not work exactly like\n> \"checkout @{-1}\", combined with the previous point of requiring\n> to be explicit when detaching HEAD, \"switch -\" that tries to go\n> back to a detached state may be justifiable---it stops you in\n> order to avoid accidental detaching of HEAD.\nYou are right, it may be justifiable. But unexpected behavior for both\nnewbies and experts may not be desirable.\n\n> Personally, I think those who are familiar with and expert enough on\n> Git and do not feel uneasy working on detached HEAD can and should\n> just use \"checkout\" not \"switch/restore\", but that may be just me.\nIsn't checkout supposed to become deprecated at some point?\nDoes it mean I can safely ignore the fact that switch exists and\ncontinue advocating for checkout instead? I am missing the point for\nthe introduction of git-switch entirely then. And as you said you were\nnot among the primary advocates to add it, I guess we should wait for\nsomeone else to reply about this?\n\nAnd I still would love to have a checkout.autoDetach or\nswitch.autoDetach option :)\n\nIn any case, thank you already for this reply <3\nMinato\n"},{"id":"480063","messageId":"xmqqleeubork.fsf@gitster.g","threadId":"59925","inReplyTo":"CACmJb3wTsWdqDGrkYC0p+eB-XYBotVcFAKcXJF3ftYdiiRvEdw@mail.gmail.com","subject":"Re: git-switch history and checkout compatibility","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-08-01T18:28:47Z","receivedAt":"2023-08-01T18:29:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Namikaze Minato writes:\n\n> Isn't checkout supposed to become deprecated at some point?\n\nDeprecating \"checkout\" hurts those who are confused by what the\nsplit \"switch/restore\" pair of commands do (cf. this very discussion\nwe are having), and folks who are happily using \"checkout\". On the\nother hand, those who are happy with \"switch/restore\" would not be\naffected by the existence of \"checkout\". So, no, I do not think it\nis part of the map to deprecate the command. At least not until the\nsplit \"switch/restore\" pair of commands become less confusing and\nlose their \"experimental\" state, that is.\n\n> ... And as you said you were\n> not among the primary advocates to add it, I guess we should wait for\n> someone else to reply about this?\n\nThere are things \"switch/restore\" pair do differently relative to\n\"checkout\". Some of them (like \"restore\" allowing checking out\npaths from tree only to the working tree files while not touching\nthe index, which is not possible with \"checkout\") are very much\nwelcome improvement, but some others (cf. this very discussion we\nare having on \"switch\") may simply not make any sense. Those who\nadvocated and pushed the split \"switch/restore\" pair should be able\nto explain why they chose to do things differently much better than\nI would be (some differences may simply be bugs waiting to be fixed\nby them).\n"}]}