{"thread":{"id":"40267","subject":"Feature Request: enhance Git-GUI's Checkout Branch screen","startedAt":"2015-09-03T17:08:24Z","lastAt":"2015-09-05T00:28:34Z","messageCount":5,"participants":["John Medema","David Aguilar","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"269344","messageId":"CALsXy+0FN1A-E-GF-chPrOpZSt-Wg8afL8BReqaUnBHDj=3NXA@mail.gmail.com","threadId":"40267","inReplyTo":null,"subject":"Feature Request: enhance Git-GUI's Checkout Branch screen","fromName":"John Medema","fromEmail":"john.medema@uniteddrugs.com","sentAt":"2015-09-03T17:08:24Z","receivedAt":"2015-09-03T17:08:24Z","isPatch":false,"sender":{"key":"john.medema@uniteddrugs.com","avatar":null},"body":"Git gurus, throw this one on your to-do list:\n\nThis is a feature request to enhance the Git GUI to make it easier to\ncheckout non-existing branches that exist upstream. Apologies if this\nis not the correct place for feature requests.\n\nScenario: Upstream repo has 4 branches - master, develop, maint, test.\nLocal repo has only a master branch. In the command line, to switch to\na local copy of the test branch, it is a simple \"git checkout test\".\nThe git command automatically realizes your requested branch doesn't\nexist but origin does have a branch named test, so it a) creates a\nlocal branch off of origin/develop, b) sets the appropriate pull link,\nand c) sets the appropriate push link. In effect, the git command line\nhides the fact that the user doesn't know the branch doesn't exist and\ncreates it as the user was expecting it to exist as. The Git GUI has\nno shortcut like this.\n\nFor reference, from the man page for git-checkout:\n\"If is not found but there does exist a tracking branch in\nexactly one remote (call it ) with a matching name, treat as\nequivalent to \"git checkout -b --track /\".\n\nCurrently, in order to checkout a non-existing branch in the GUI you\nmust go to the Branch Menu, click Create, select the \"Tracking Branch\"\nradio, select the branch, then go back up and name the branch the\nexact same name (to ease new user confusion). For a new user who just\nwants a copy of the remote branch, it is very unintuitive to create a\nnew branch.\n\nFortunately, you already have some explicit warning messages after the\nCheckout Branch screen if the user intuitively tries to checkout the\ntracking branch, but even then a new user rarely realizes what they\nhave gotten themselves into. At best, they know that they must find\nhelp (just for trying to checkout a branch).\n\nIn order to implement this feature effectively, I suggest that the\nCheckout Branch screen be modified in one of two ways (exclusive):\n\nOption A:\nMerge the Local and Tracking Branch lists into one box keeping their\nentries separate by their full name (\"master\" and \"origin/master\"). If\na user selects a remote branch, ask the user whether to create the\nlocal branch or move to the detached HEAD state (current\nfunctionality).\n\nOption B (preferred):\nKeep the Local and Tracking Branch lists separate (as they are now),\nand keep the Tracking Branch list as-is. However, on the Local Branch\nscreen, select include the existing branches in normal font but also\ninclude potential local branches based off of the remote in italics\n(or greyed-out, or asterisked, etc). Selecting an italicized entry\ncreates the new branch from the tracking branch, without user\ninteraction.\n\n\nThanks,\n\nJohn Medema\nSystems Administrator\nUnited Drugs, a Subsidiary of AAP (American Associated Pharmacies)\njohn.medema@uniteddrugs.com\n7243 N 16th Street, Phoenix, AZ 85020\nOffice: 602-678-1179 x126\nFax: 602-639-4631\n\n-- \nHIPAA NOTICE: It is against United Drugs’ policy to receive or send \nun-encrypted or non-secured email correspondence containing Protected \nHealth Information (PHI) as defined by HIPAA law.\n \nPlease use fax or phone for correspondence containing PHI.\n\n-- \nThis email message is for the sole use of the intended recipient(s) and may \ncontain confidential and privileged information. Any unauthorized review, \nuse, disclosure or distribution is prohibited. If you are not the intended \nrecipient, contact the sender by reply email, and destroy all copies of the \noriginal message. \n"},{"id":"269395","messageId":"20150904044224.GA20164@gmail.com","threadId":"40267","inReplyTo":"CALsXy+0FN1A-E-GF-chPrOpZSt-Wg8afL8BReqaUnBHDj=3NXA@mail.gmail.com","subject":"Re: Feature Request: enhance Git-GUI's Checkout Branch screen","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2015-09-04T04:42:24Z","receivedAt":"2015-09-04T04:42:24Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Thu, Sep 03, 2015 at 10:08:24AM -0700, John Medema wrote:\n> Git gurus, throw this one on your to-do list:\n> \n> This is a feature request to enhance the Git GUI to make it easier to\n> checkout non-existing branches that exist upstream. Apologies if this\n> is not the correct place for feature requests.\n> \n> Scenario: Upstream repo has 4 branches - master, develop, maint, test.\n> Local repo has only a master branch. In the command line, to switch to\n> a local copy of the test branch, it is a simple \"git checkout test\".\n> The git command automatically realizes your requested branch doesn't\n> exist but origin does have a branch named test, so it a) creates a\n> local branch off of origin/develop, b) sets the appropriate pull link,\n> and c) sets the appropriate push link. In effect, the git command line\n> hides the fact that the user doesn't know the branch doesn't exist and\n> creates it as the user was expecting it to exist as. The Git GUI has\n> no shortcut like this.\n> \n> For reference, from the man page for git-checkout:\n> \"If is not found but there does exist a tracking branch in\n> exactly one remote (call it ) with a matching name, treat as\n> equivalent to \"git checkout -b --track /\".\n> \n> Currently, in order to checkout a non-existing branch in the GUI you\n> must go to the Branch Menu, click Create, select the \"Tracking Branch\"\n> radio, select the branch, then go back up and name the branch the\n> exact same name (to ease new user confusion). For a new user who just\n> wants a copy of the remote branch, it is very unintuitive to create a\n> new branch.\n> \n> Fortunately, you already have some explicit warning messages after the\n> Checkout Branch screen if the user intuitively tries to checkout the\n> tracking branch, but even then a new user rarely realizes what they\n> have gotten themselves into. At best, they know that they must find\n> help (just for trying to checkout a branch).\n> \n> In order to implement this feature effectively, I suggest that the\n> Checkout Branch screen be modified in one of two ways (exclusive):\n> \n> Option A:\n> Merge the Local and Tracking Branch lists into one box keeping their\n> entries separate by their full name (\"master\" and \"origin/master\"). If\n> a user selects a remote branch, ask the user whether to create the\n> local branch or move to the detached HEAD state (current\n> functionality).\n> \n> Option B (preferred):\n> Keep the Local and Tracking Branch lists separate (as they are now),\n> and keep the Tracking Branch list as-is. However, on the Local Branch\n> screen, select include the existing branches in normal font but also\n> include potential local branches based off of the remote in italics\n> (or greyed-out, or asterisked, etc). Selecting an italicized entry\n> creates the new branch from the tracking branch, without user\n> interaction.\n\nHow about Option C?\n\nWhat git-cola[1] has done for the longest time is when the\nremote branch is selected it strips of the remote part and\nautomatically fills in the name field with that. e.g. it fills\nin \"todo\" when \"origin/todo\" is selected.\n\nMixing remote branches with pseudo-branches in the UI would\ncomplicate it, so that seems like it could be made simpler.\nItalics, asterisks, those are all signs that they shouldn't\nbe displayed next to each other.\n\nI think the UI is fine as-is. If it were just tweaked to\nautomatically fill in that field, like git-cola does, then it\ncan stay simple and make this use case easier.\n\nIf you're looking for other interesting usability things that\ncould be improved about git-gui, take a look at the\nkeyboard-driven user interface features in git-cola. It's\noptimized for keyboard-centric use.\n\n[1] https://github.com/git-cola/git-cola\n-- \nDavid\n"},{"id":"269439","messageId":"CALsXy+2N++xDXiiX2q1p43Sk7hW1Uh7oeQQO25Fp23H21JJpxg@mail.gmail.com","threadId":"40267","inReplyTo":"20150904044224.GA20164@gmail.com","subject":"Re: Feature Request: enhance Git-GUI's Checkout Branch screen","fromName":"John Medema","fromEmail":"john.medema@uniteddrugs.com","sentAt":"2015-09-04T18:40:14Z","receivedAt":"2015-09-04T18:40:14Z","isPatch":false,"sender":{"key":"john.medema@uniteddrugs.com","avatar":null},"body":"David,\n\nOption C - when you say \"[in git-cola] when the remote branch is\nselected it strips of the remote part and automatically fills in the\nname field with that\", are you referring to the Branch Create screen\nor the Branch Checkout screen? Your description matches the Create\nscreen. And for what its worth, that description is accurate and I\nagree that cola does a good job of making the branch creation process\neasy, and the branch creation process would definitely be improved by\nyour suggestion.\n\nBut as the company's unofficial git admin, I get new git users coming\nto me frequently for help and the single most frequent new user\nmistake is that the users don't know that they need to create a local\nbranch in the first place. They assume a clone really means cloning\nand that all the branches from upstream have been created locally on a\nclone. The bash users don't even realize they're creating a branch\nwhen the run \"git checkout myNewBranch\" - they think they're checking\nout an existing branch. The gui users don't have that shortcut\ncurrently; they can only checkout existing local branches or remote\nbranches as a detached head. I'm trying to point out here that in\nthis (single) use case its actually easier to use the command line\nthan the gui.\n\nGranted, an argument can made that the new users should know what\nthey're doing before they dive into things like an SCM. While in\ngeneral I agree, there's also something to be said for making things\neasier when it does not impact functionality. For example, git-cola's\nBranch Checkout UI allows you to type in the name of a tracked branch\nthat doesn't exist yet locally. If you type in \"origin/myBranch\" you\nget a detached head. If you type in \"myBranch\", cola will create the\nlocal branch off of origin/myBranch (as you and I would expect). Of\ncourse, this cola UI can still be improved too - it doesn't show you\nthat potential branch in the checkout dropdown list, requiring you to\ntype it in. And to make matters worse, if you type it in wrong the\nbranch checkout silently fails and you stay in your starting branch.\nBut that isn't your problem.\n\nSo I'm not a fan of Option C, where the user is still forced to use\nBranch Create. So what do you think of Option D?\n\nFor both the GUI and the command line, during Git Clone operation,\nafter the existing process completes, the clone action also creates\neach remote branch locally. This bypasses all the problems above, and\nhas the added benefit of making a clone operation more clone-like\n(i.e. it makes the local repository exactly like the upstream\nrepository). The starting local branch can still use the upstream's\n\"default branch\" setting. I've never understood why git didn't do\nthis since its just adding a pointer to a commit (for each branch).\nIs it an attempt to prune the old branch clutter when a repo is cloned\nfrom another repo that is itself cloned (i.e. to remove unused\nbranches from the grandfather repo)?\n\nOption D has the downside that it changes the behavior of more code\n(cmdline and gui), which is why I didn't suggest it before. It also\nhas the downside of making the branch list longer. But that's the\nnature of cloning; if I copy a full directory of files to a new\ndirectory I expect to get a full set of files. If I plan on only\nusing a small subset of files its up to me to remove them after I've\ncopied them (I'm assuming that I don't know what files/branches I want\nbeforehand, which is why I'm copying everything).\n\nSorry if I overloaded your monitor with all these characters, I'm\ntrying to anticipate responses. Thanks for your time,\n\n\nJohn Medema\nSystems Administrator\nUnited Drugs, a Subsidiary of AAP (American Associated Pharmacies)\njohn.medema@uniteddrugs.com\n7243 N 16th Street, Phoenix, AZ 85020\nOffice: 602-678-1179 x126\nFax: 602-639-4631\n\n\nOn Thu, Sep 3, 2015 at 9:42 PM, David Aguilar wrote:\n> On Thu, Sep 03, 2015 at 10:08:24AM -0700, John Medema wrote:\n>> Git gurus, throw this one on your to-do list:\n>>\n>> This is a feature request to enhance the Git GUI to make it easier to\n>> checkout non-existing branches that exist upstream. Apologies if this\n>> is not the correct place for feature requests.\n>>\n>> Scenario: Upstream repo has 4 branches - master, develop, maint, test.\n>> Local repo has only a master branch. In the command line, to switch to\n>> a local copy of the test branch, it is a simple \"git checkout test\".\n>> The git command automatically realizes your requested branch doesn't\n>> exist but origin does have a branch named test, so it a) creates a\n>> local branch off of origin/develop, b) sets the appropriate pull link,\n>> and c) sets the appropriate push link. In effect, the git command line\n>> hides the fact that the user doesn't know the branch doesn't exist and\n>> creates it as the user was expecting it to exist as. The Git GUI has\n>> no shortcut like this.\n>>\n>> For reference, from the man page for git-checkout:\n>> \"If is not found but there does exist a tracking branch in\n>> exactly one remote (call it ) with a matching name, treat as\n>> equivalent to \"git checkout -b --track /\".\n>>\n>> Currently, in order to checkout a non-existing branch in the GUI you\n>> must go to the Branch Menu, click Create, select the \"Tracking Branch\"\n>> radio, select the branch, then go back up and name the branch the\n>> exact same name (to ease new user confusion). For a new user who just\n>> wants a copy of the remote branch, it is very unintuitive to create a\n>> new branch.\n>>\n>> Fortunately, you already have some explicit warning messages after the\n>> Checkout Branch screen if the user intuitively tries to checkout the\n>> tracking branch, but even then a new user rarely realizes what they\n>> have gotten themselves into. At best, they know that they must find\n>> help (just for trying to checkout a branch).\n>>\n>> In order to implement this feature effectively, I suggest that the\n>> Checkout Branch screen be modified in one of two ways (exclusive):\n>>\n>> Option A:\n>> Merge the Local and Tracking Branch lists into one box keeping their\n>> entries separate by their full name (\"master\" and \"origin/master\"). If\n>> a user selects a remote branch, ask the user whether to create the\n>> local branch or move to the detached HEAD state (current\n>> functionality).\n>>\n>> Option B (preferred):\n>> Keep the Local and Tracking Branch lists separate (as they are now),\n>> and keep the Tracking Branch list as-is. However, on the Local Branch\n>> screen, select include the existing branches in normal font but also\n>> include potential local branches based off of the remote in italics\n>> (or greyed-out, or asterisked, etc). Selecting an italicized entry\n>> creates the new branch from the tracking branch, without user\n>> interaction.\n>\n> How about Option C?\n>\n> What git-cola[1] has done for the longest time is when the\n> remote branch is selected it strips of the remote part and\n> automatically fills in the name field with that. e.g. it fills\n> in \"todo\" when \"origin/todo\" is selected.\n>\n> Mixing remote branches with pseudo-branches in the UI would\n> complicate it, so that seems like it could be made simpler.\n> Italics, asterisks, those are all signs that they shouldn't\n> be displayed next to each other.\n>\n> I think the UI is fine as-is. If it were just tweaked to\n> automatically fill in that field, like git-cola does, then it\n> can stay simple and make this use case easier.\n>\n> If you're looking for other interesting usability things that\n> could be improved about git-gui, take a look at the\n> keyboard-driven user interface features in git-cola. It's\n> optimized for keyboard-centric use.\n>\n> [1] https://github.com/git-cola/git-cola\n> --\n> David\n\n-- \nHIPAA NOTICE: It is against United Drugs’ policy to receive or send \nun-encrypted or non-secured email correspondence containing Protected \nHealth Information (PHI) as defined by HIPAA law.\n \nPlease use fax or phone for correspondence containing PHI.\n\n-- \nThis email message is for the sole use of the intended recipient(s) and may \ncontain confidential and privileged information. Any unauthorized review, \nuse, disclosure or distribution is prohibited. If you are not the intended \nrecipient, contact the sender by reply email, and destroy all copies of the \noriginal message. \n"},{"id":"269451","messageId":"xmqq37ytg79g.fsf@gitster.mtv.corp.google.com","threadId":"40267","inReplyTo":"CALsXy+2N++xDXiiX2q1p43Sk7hW1Uh7oeQQO25Fp23H21JJpxg@mail.gmail.com","subject":"Re: Feature Request: enhance Git-GUI's Checkout Branch screen","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-09-04T22:16:27Z","receivedAt":"2015-09-04T22:16:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Medema writes:\n\n> Option D has the downside that it changes the behavior of more code\n> (cmdline and gui), which is why I didn't suggest it before. It also\n> has the downside of making the branch list longer. But that's the\n> nature of cloning; if I copy a full directory of files to a new\n> directory I expect to get a full set of files.\n\nYou shouldn't be too literal with the word \"clone\". The reason\npeople \"clone\" a project often is to work on their own thing, which\nmay be based only on a handful of branches the upstream publishes.\n\nSo I do necessarily buy \"But that's the nature\" argument myself.\n\nNot doing your option D has another benefit, other than \"smaller\nnumber of branches\" you mentioned, and it is more important one in\npractice. Once you start your own development with your own set of\nbranches, you want to see the names of _your_ branches in your\nrepository, not mixed with 47 other uninteresting branches your\nupstream has for its purpose. Whey you are working on fixing\nsomething for the maintenance track of the upstream, you do want to\nsee your 'fix-that-thing' local branch forked from 'maint' branch of\nthe upstream, and you may or may not also want to see a copy of\n'maint' branch in your local branch namespace, but you certainly do\nnot want to see 'master', 'next', 'pu' and all the topic branches\nthe upstream uses to build and advance these branches ahead of\n'maint' that you are currently focusing on.\n\nIn fact, with ancient versions of Git, you got copies of all\nbranches your upstream has as your local branches. This turned to\nbe unusable and was corrected at around v1.5.0 release---this was\ndone primarily so that we can have a sane remote-tracking, but\nuncluttering the local branch space was also a reason why we\ntransitioned to the current \"separate remote\" layout.\n"},{"id":"269461","messageId":"CALsXy+3X7aB0xN17wgPCwR+C6-PmbNBPwLZ9huhyfp2BSrtEog@mail.gmail.com","threadId":"40267","inReplyTo":"xmqq37ytg79g.fsf@gitster.mtv.corp.google.com","subject":"Re: Feature Request: enhance Git-GUI's Checkout Branch screen","fromName":"John Medema","fromEmail":"john.medema@uniteddrugs.com","sentAt":"2015-09-05T00:28:34Z","receivedAt":"2015-09-05T00:28:34Z","isPatch":false,"sender":{"key":"john.medema@uniteddrugs.com","avatar":null},"body":"Junio,\n\nI can appreciate the amount of clutter you'd get with the ancient\nbehavior. That said, I'd be willing to live with it. I personally\nprefer to see all the branches coming and going - if the branches are\ngood enough for upstream, they're good enough for me (I'm really good\nan ignoring stuff).\n\nRealizing I'm probably not in the majority, I'd think that re-enabling\nthis ancient behavior as a non-default option (like git config\npush.default) might be nice for those of my inclination. As of now I\nneed to write a script to do a fetch + create_branch( diff( local vs\norigin ) ).\n\nBut like I said before, I was hoping I'd have an easier time\nconvincing you guys on Options A or B to make the gui more consistent\nwith the cmdline.\n\nThanks,\n\nJohn Medema\nSystems Administrator\nUnited Drugs, a Subsidiary of AAP (American Associated Pharmacies)\njohn.medema@uniteddrugs.com\n7243 N 16th Street, Phoenix, AZ 85020\nOffice: 602-678-1179 x126\nFax: 602-639-4631\n\n\nOn Fri, Sep 4, 2015 at 3:16 PM, Junio C Hamano wrote:\n> John Medema writes:\n>\n>> Option D has the downside that it changes the behavior of more code\n>> (cmdline and gui), which is why I didn't suggest it before. It also\n>> has the downside of making the branch list longer. But that's the\n>> nature of cloning; if I copy a full directory of files to a new\n>> directory I expect to get a full set of files.\n>\n> You shouldn't be too literal with the word \"clone\". The reason\n> people \"clone\" a project often is to work on their own thing, which\n> may be based only on a handful of branches the upstream publishes.\n>\n> So I do necessarily buy \"But that's the nature\" argument myself.\n>\n> Not doing your option D has another benefit, other than \"smaller\n> number of branches\" you mentioned, and it is more important one in\n> practice. Once you start your own development with your own set of\n> branches, you want to see the names of _your_ branches in your\n> repository, not mixed with 47 other uninteresting branches your\n> upstream has for its purpose. Whey you are working on fixing\n> something for the maintenance track of the upstream, you do want to\n> see your 'fix-that-thing' local branch forked from 'maint' branch of\n> the upstream, and you may or may not also want to see a copy of\n> 'maint' branch in your local branch namespace, but you certainly do\n> not want to see 'master', 'next', 'pu' and all the topic branches\n> the upstream uses to build and advance these branches ahead of\n> 'maint' that you are currently focusing on.\n>\n> In fact, with ancient versions of Git, you got copies of all\n> branches your upstream has as your local branches. This turned to\n> be unusable and was corrected at around v1.5.0 release---this was\n> done primarily so that we can have a sane remote-tracking, but\n> uncluttering the local branch space was also a reason why we\n> transitioned to the current \"separate remote\" layout.\n\n-- \nHIPAA NOTICE: It is against United Drugs’ policy to receive or send \nun-encrypted or non-secured email correspondence containing Protected \nHealth Information (PHI) as defined by HIPAA law.\n \nPlease use fax or phone for correspondence containing PHI.\n\n-- \nThis email message is for the sole use of the intended recipient(s) and may \ncontain confidential and privileged information. Any unauthorized review, \nuse, disclosure or distribution is prohibited. If you are not the intended \nrecipient, contact the sender by reply email, and destroy all copies of the \noriginal message. \n"}]}