{"thread":{"id":"43276","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","startedAt":"2006-11-06T23:26:16Z","lastAt":"2006-11-07T17:04:43Z","messageCount":14,"participants":["Josef Weidendorfer","Junio C Hamano","Karl Hasselström"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"297565","messageId":"200611070026.16425.Josef.Weidendorfer@gmx.de","threadId":"43276","inReplyTo":null,"subject":"[PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-06T23:26:16Z","receivedAt":"2006-11-06T23:26:16Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"- When requested to checkout read-only remote branches,\n we try to create a new local development branch with same name.\n- When we branch off a remote branch, set up default merge source.\n---\n\nThis patch does the sensible thing when the user requests to\ncheck-out a remote read-only branch (eg. origin/master).\nIt also automatically sets up the default merge source (with remote\nentry) for a new branch.\n\nExample to hack on git's next branch:\n\n git-clone --use-separate-remote http://www.kernel.org/pub/scm/git/git.git\n cd git\n git-checkout origin/next\n \n git pull (to merge patches from remote 'next')\n\nThe checkout creates local branch 'master' to checkout read-only remote branch\n'remotes/origin/master'. Additionally, it sets up 'remotes/origin/master' from\nremote repository 'origin' as default merge source for the new development branch.\n\nMissing:\n- \"git branch -D \" should remove remote branch attributes like\n \"remote\" and \"merge\"\n- As \"git-clone\" already sets up a local development branch \"master\", it also\n should set up a default merge source for it\n\nJosef\n\n git-checkout.sh | 29 +++++++++++++++++++++++++++++\n 1 files changed, 29 insertions(+), 0 deletions(-)\n\ndiff --git a/git-checkout.sh b/git-checkout.sh\nindex 119bca1..63b622e 100755\n--- a/git-checkout.sh\n+++ b/git-checkout.sh\n@@ -12,6 +12,8 @@ force=\n branch=\n newbranch=\n newbranch_log=\n+remote=\n+remotebranch=\n merge=\n while [ \"$#\" != \"0\" ]; do\n arg=\"$1\"\n@@ -55,6 +57,11 @@ while [ \"$#\" != \"0\" ]; do\n \t\t\tthen\n \t\t\t\tbranch=\"$arg\"\n \t\t\tfi\n+\t\t\tif git-show-ref --verify --quiet -- \"refs/remotes/$arg\"\n+\t\t\tthen\n+\t\t\t\tremote=$(echo $arg | sed -ne 's!/.*$!!p')\n+\t\t\t\tremotebranch=$(echo $arg | sed -e 's!^.*/!!')\n+\t\t\tfi\n \t\telif rev=$(git-rev-parse --verify \"$arg^{tree}\" 2>/dev/null)\n \t\tthen\n \t\t\t# checking out selected paths from a tree-ish.\n@@ -77,6 +84,20 @@ while [ \"$#\" != \"0\" ]; do\n esac\n done\n \n+# Create a new local branch when checking out remote read-only branch\n+if test -z \"$newbranch\" -a ! -z \"$remotebranch\"\n+then\n+\tnewbranch=$remotebranch\n+\tif git-show-ref --verify --quiet -- \"refs/heads/$newbranch\"\n+\tthen\n+\t\techo \"Proposed new branch '$newbranch' to checkout read-only remote branch 'remotes/$remote/$remotebranch' exists!\"\n+\t\techo \"To checkout, specify a new branch name with -b\"\n+\t\texit 1\n+\tfi\n+\techo \"Creating local branch '$newbranch' to checkout read-only remote branch 'remotes/$remote/$remotebranch'.\"\n+fi\n+\n+\n # The behaviour of the command with and without explicit path\n # parameters is quite different.\n #\n@@ -211,6 +232,14 @@ if [ \"$?\" -eq 0 ]; then\n \t\t\ttouch \"$GIT_DIR/logs/refs/heads/$newbranch\"\n \t\tfi\n \t\tgit-update-ref -m \"checkout: Created from $new_name\" \"refs/heads/$newbranch\" $new || exit\n+\n+\t\tif test '' != \"$remote\"\n+\t\tthen\n+\t\t\techo \"Using 'remotes/$remote/$remotebranch' from remote repository '$remote' as default merge source.\"\n+\t\t\tgit-repo-config branch.\"$newbranch\".remote \"$remote\"\n+\t\t\tgit-repo-config branch.\"$newbranch\".merge \"remotes/$remote/$remotebranch\"\n+\t\tfi\n+\n \t\tbranch=\"$newbranch\"\n \tfi\n \t[ \"$branch\" ] &&\n-- \n1.4.3.rc2.gf8ffb\n"},{"id":"296549","messageId":"200611070030.53935.Josef.Weidendorfer@gmx.de","threadId":"43276","inReplyTo":"200611070026.16425.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-06T23:30:53Z","receivedAt":"2006-11-06T23:30:53Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"Oops.\n\nCorrections in example:\n\nOn Tuesday 07 November 2006 00:26, Josef Weidendorfer wrote:\n> Example to hack on git's next branch:\n> \n> git-clone --use-separate-remote http://www.kernel.org/pub/scm/git/git.git\n> cd git\n> git-checkout origin/next\n> \n> git pull (to merge patches from remote 'next')\n> \n> The checkout creates local branch 'master' to checkout read-only remote branch\n ^ next\n> 'remotes/origin/master'. Additionally, it sets up 'remotes/origin/master' from\n ^next ^next\n> remote repository 'origin' as default merge source for the new development branch.\n\n"},{"id":"297892","messageId":"7vd580azbb.fsf@assigned-by-dhcp.cox.net","threadId":"43276","inReplyTo":"200611070026.16425.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-07T00:13:44Z","receivedAt":"2006-11-07T00:13:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer writes:\n\n> Example to hack on git's next branch:\n>\n> git-clone --use-separate-remote http://www.kernel.org/pub/scm/git/git.git\n> cd git\n> git-checkout origin/next\n> \n> git pull (to merge patches from remote 'next')\n>\n> The checkout creates local branch 'next' to checkout read-only\n> remote branch 'remotes/origin/next'. Additionally, it sets up\n> 'remotes/origin/next' from remote repository 'origin' as\n> default merge source for the new development branch.\n\nI am disturbed by an inconsistency here.\n\n> +\tif git-show-ref --verify --quiet -- \"refs/heads/$newbranch\"\n> +\tthen\n> +\t\techo \"Proposed new branch '$newbranch' to checkout...\n> +\t\techo \"To checkout, specify a new branch name with -b\"\n> +\t\texit 1\n> +\tfi\n\nThis logic is guarding against already having a local branch\nthat is called 'next', and that is why the \"Proposed new branch\"\nmessage needs to be there. One explanation of why 'next' exists\nin the local branch namespace in the first place is probably\nthere are other remote branches than origin that have 'next' and\nthe user previously checked it out. Or perhaps the user has\nalready done this \"checkout origin/next\" once already.\n\nI wonder if it is more consistent and easy to use to just make\nthis:\n\n\tgit checkout origin/next\n\na synonym to:\n\n\tgit checkout -b origin/next remotes/origin/next\n\nwhen remotes/origin/next exists and heads/origin/next does not.\n\nThen \"git checkout origin/next\" would always mean \"I want to\nswitch to the branch I use to hack on the branch 'next' Junio\nhas\". Do it once and you will get exactly my tip, hack on it,\nswitch out of it and then do it again and you won't lose your\nprevious work but just switch to that branch.\n\nThat is, something like this...\n\n---\n\ndiff --git a/git-checkout.sh b/git-checkout.sh\nindex 119bca1..f6486c6 100755\n--- a/git-checkout.sh\n+++ b/git-checkout.sh\n@@ -4,6 +4,16 @@ USAGE='[-f] [-b ] [-m] [&2 \"* Forking local branch $1 off of remotes/$1...\"\n+\tshift\n+fi\n+\n old_name=HEAD\n old=$(git-rev-parse --verify $old_name 2>/dev/null)\n new=\n"},{"id":"295600","messageId":"200611070225.24956.Josef.Weidendorfer@gmx.de","threadId":"43276","inReplyTo":"7vd580azbb.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-07T01:25:24Z","receivedAt":"2006-11-07T01:25:24Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 07 November 2006 01:13, Junio C Hamano wrote:\n\n> I wonder if it is more consistent and easy to use to just make\n> this:\n> \n> \tgit checkout origin/next\n> \n> a synonym to:\n> \n> \tgit checkout -b origin/next remotes/origin/next\n> \n> when remotes/origin/next exists and heads/origin/next does not.\n\nInteresting.\n\nI wonder how often there is a real need for that long branch names.\nIMHO this convenience behavior of git-checkout should target\nthe majority of possible use cases. Is it really better to default\nto long branch names instead of asking for explicit branch name\nin the rare case of conflict (ie. multiple remote repositories with\nsame branch names and you want to develop on both these branches\nlocally)?\n\nSuppose developer2 uses this scheme, and has a local development\nbranch \"junio/next\", which is based on your \"next\" branch.\nNow I want to work on the \"next\" branch of developer2, getting\na local branch name \"developer2/junio/next\".\n\n> Then \"git checkout origin/next\" would always mean \"I want to\n> switch to the branch I use to hack on the branch 'next' Junio\n> has\". Do it once and you will get exactly my tip, hack on it,\n> switch out of it and then do it again and you won't lose your\n> previous work but just switch to that branch.\n\nAh, now I understand your thinking.\nI admit it has a compelling elegance.\n\nHowever.\nWould it not be confusing for newbies (and not only for them) to\nfirst reference the remote branch with \"origin/next\", and afterwards, you\nget your own development branch by using the exactly same name?\n\nIMHO this kind of aliasing is awkward. When you want to start another\ntopic branch on the remote branch, or want to reference the remote\nbranch for diffs, you have to explicitly specify \"remotes/origin/next\",\nmaking for more typing.\n\n> That is, something like this...\n> \n> ---\n> \n> diff --git a/git-checkout.sh b/git-checkout.sh\n> index 119bca1..f6486c6 100755\n> --- a/git-checkout.sh\n> +++ b/git-checkout.sh\n> @@ -4,6 +4,16 @@ USAGE='[-f] [-b ] [-m] [ SUBDIRECTORY_OK=Sometimes\n> . git-sh-setup\n> \n> +# Automatic forking of local branch based on remote\n> +if test $# = 1 &&\n> + git show-ref --verify --quiet -- \"refs/remotes/$1\" &&\n> + ! git show-ref --verify --quiet -- \"refs/heads/$1\"\n> +then\n> +\tset x -b \"$1\" \"remotes/$1\"\n> +\techo >&2 \"* Forking local branch $1 off of remotes/$1...\"\n> +\tshift\n> +fi\n\nI didn't know about \"set x\" before.\nThanks, you never end learning :-)\n\n\"git-checkout remotes/origin/next\" does not work as expected,\nand if fixed, it still should guard against an existing\nlocal branch \"origin/next\", don't you think?\n(Ok, it does not work in my patch, too.)\n\nWhat do you think about the setup of the default for \"git-pull\"?\n\n"},{"id":"297136","messageId":"7vd5809fnh.fsf@assigned-by-dhcp.cox.net","threadId":"43276","inReplyTo":"200611070225.24956.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-07T02:03:46Z","receivedAt":"2006-11-07T02:03:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer writes:\n\n> What do you think about the setup of the default for \"git-pull\"?\n\nI personally feel that is loading \"checkout\" with too many\ndifferent things.\n\nIt might be easier to maintain in the long term to have a helper\ncommand 'git-fork' to handle the gory details of forking off\nfrom an existing branch (merge default setting, branch creation,\nwhat else will we have next month? ;-) and perhaps automatically\ncall it from git-checkout as a short-hand.\n"},{"id":"295131","messageId":"7v7iy89ffs.fsf@assigned-by-dhcp.cox.net","threadId":"43276","inReplyTo":"7vd5809fnh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-07T02:08:23Z","receivedAt":"2006-11-07T02:08:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Josef Weidendorfer writes:\n>\n>> What do you think about the setup of the default for \"git-pull\"?\n>\n> I personally feel that is loading \"checkout\" with too many\n> different things.\n>\n> It might be easier to maintain in the long term to have a helper\n> command 'git-fork' to handle the gory details of forking off\n> from an existing branch (merge default setting, branch creation,\n> what else will we have next month? ;-) and perhaps automatically\n> call it from git-checkout as a short-hand.\n\nAh, one should never open one's mouth before thinking things\ntwice and then sleeping on it.\n\nI do not think we want a _new_ command. It may make sense to\nenrich 'git-branch' for that.\n\nIf \"git-checkout -b\" does not use 'git-branch' to create a new\nbranch in the current code, maybe we should, regardless of the\nusability enhancements under discussion.\n\n\n"},{"id":"298444","messageId":"7vvels6lf4.fsf@assigned-by-dhcp.cox.net","threadId":"43276","inReplyTo":"200611070225.24956.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-07T02:27:27Z","receivedAt":"2006-11-07T02:27:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer writes:\n\n>> Then \"git checkout origin/next\" would always mean \"I want to\n>> switch to the branch I use to hack on the branch 'next' Junio\n>> has\". Do it once and you will get exactly my tip, hack on it,\n>> switch out of it and then do it again and you won't lose your\n>> previous work but just switch to that branch.\n>\n> Ah, now I understand your thinking.\n> I admit it has a compelling elegance.\n>\n> However.\n> Would it not be confusing for newbies (and not only for them) to\n> first reference the remote branch with \"origin/next\", and afterwards, you\n> get your own development branch by using the exactly same name?\n\nWhen we get these per-branch attributes used widely enough, we\nmight add new vocabulary to our extended sha1 expressions that\ndenotes \"the branch I forked this branch off of\".\n\nIf refs/heads/next is created from refs/remotes/origin/next,\nperhaps with an updated git-branch command that knows how to\nhelp set things up, we might want to be able to refer to\nremotes/origin/next as \"next's upstream\". While we are on\n'next' branch, we might want to refer to \"HEAD's upstream\".\n\nI am not sure what the syntax for that should be, though.\nPerhaps \"HEAD@upstream\"?\n\nUnlike the regular extended sha1 expression modifiers such as\nname~n, name^n, and name^{type}, it does not work with arbitrary\nobject name; it can only work with a refname. Which is similar\nto the '@{time}' notation we added when we started using\nref-log. Strictly speaking these should not belong to the sha1\nnaming layer, but we can have them anyway for the user's\nconvenience.\n"},{"id":"297577","messageId":"20061107065400.GA25737@diana.vm.bytemark.co.uk","threadId":"43276","inReplyTo":"200611070225.24956.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-11-07T06:54:00Z","receivedAt":"2006-11-07T06:54:00Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-11-07 02:25:24 +0100, Josef Weidendorfer wrote:\n\n> On Tuesday 07 November 2006 01:13, Junio C Hamano wrote:\n>\n> > Then \"git checkout origin/next\" would always mean \"I want to\n> > switch to the branch I use to hack on the branch 'next' Junio\n> > has\". Do it once and you will get exactly my tip, hack on it,\n> > switch out of it and then do it again and you won't lose your\n> > previous work but just switch to that branch.\n>\n> Ah, now I understand your thinking. I admit it has a compelling\n> elegance.\n\nI agree. The name is slightly longer than necessary in the common case\nof only one remote repository, but the reduction of newbie confusion\nwill be worth it. (Non-newbies know how to give the branch any name\nthey want.)\n\n> However. Would it not be confusing for newbies (and not only for\n> them) to first reference the remote branch with \"origin/next\", and\n> afterwards, you get your own development branch by using the exactly\n> same name?\n\nNot necessarily. As long as they know that there are two kinds of\nbranches, remote and local, it should be perfectly obvious. You check\nout and modify your local copy of a remote branch, and occasionally\npull updates from the remote branch. If there is no local branch\ncorresponding to a certain remote branch, git will make one for you.\n\n> IMHO this kind of aliasing is awkward. When you want to start\n> another topic branch on the remote branch, or want to reference the\n> remote branch for diffs, you have to explicitly specify\n> \"remotes/origin/next\", making for more typing.\n\nHaving more than one local branch for a remote branch is advanced\nenough that the user should know how to create branches with any name\nthey choose.\n\nBut I do agree that calling it \"origin/next\" the first time you\nbranch, and \"remotes/origin/next\" subsequent times, is nonintuitive.\nHowever, this could be solved by the following message being printed\nthe first time:\n\n $ git checkout origin/next\n No local branch \"origin/next\" exists. Creating new local branch\n \"origin/next\" off of remote branch \"remotes/origin/next\".\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"296168","messageId":"7vlkmn7n0j.fsf@assigned-by-dhcp.cox.net","threadId":"43276","inReplyTo":"200611070225.24956.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-07T07:07:40Z","receivedAt":"2006-11-07T07:07:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer writes:\n\n>> Then \"git checkout origin/next\" would always mean \"I want to\n>> switch to the branch I use to hack on the branch 'next' Junio\n>> has\". Do it once and you will get exactly my tip, hack on it,\n>> switch out of it and then do it again and you won't lose your\n>> previous work but just switch to that branch.\n>\n> Ah, now I understand your thinking.\n> I admit it has a compelling elegance.\n>\n> However.\n> Would it not be confusing for newbies (and not only for them) to\n> first reference the remote branch with \"origin/next\", and afterwards, you\n> get your own development branch by using the exactly same name?\n\nIn that example, the user types \"git checkout origin/next\". I\ndo not think there is any confusion.\n\nYou come from git background from the era git checkout did _not_\nhave this magic (in other words, \"today\"), so you implicitly see\nremotes/ prefixed in front of the \"origin/next\" string there.\n\nBut new people do not see remotes/ prefixed there. To them, the\nexample command line says \"Now I want to be on my 'origin/next'\nbranch\", and there is nothing 'remote' about it.\n\nThe magic under discussion happens to create your 'origin/next'\nbranch automagically from 'remotes/origin/next' when it exists,\nbut that can be transparent to the user [*1*].\n\nWell, your original magic did not propose it that way, but I\ntwisted it.\n\n[Footnote]\n\n*1* This is in line with what I wanted to say in my earlier \"if\n I were redoing git from scratch\" message when I talked about\n making \"remotes\" less visible.\n\n\n\n\n"},{"id":"294668","messageId":"200611071118.28302.Josef.Weidendorfer@gmx.de","threadId":"43276","inReplyTo":"7v7iy89ffs.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-07T10:18:27Z","receivedAt":"2006-11-07T10:18:27Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 07 November 2006 03:08, you wrote:\n> I do not think we want a _new_ command. It may make sense to\n> enrich 'git-branch' for that.\n\nI agree.\n\nProbably similar, git-clone should use git-checkout at the end.\n\n> If \"git-checkout -b\" does not use 'git-branch' to create a new\n> branch in the current code, maybe we should, regardless of the\n> usability enhancements under discussion.\n\nYes.\n\nJosef\n\nPS: This is one of the moments I wished git-branch still was a shell\n"},{"id":"294405","messageId":"200611071128.18831.Josef.Weidendorfer@gmx.de","threadId":"43276","inReplyTo":"7vvels6lf4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-07T10:28:18Z","receivedAt":"2006-11-07T10:28:18Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 07 November 2006 03:27, Junio C Hamano wrote:\n> remotes/origin/next as \"next's upstream\". While we are on\n> 'next' branch, we might want to refer to \"HEAD's upstream\".\n> \n> I am not sure what the syntax for that should be, though.\n> Perhaps \"HEAD@upstream\"?\n\nI remember an idea floating around was to use a virtual\nbranch \"ORIGIN\" which always maps to the upstream of the current\nbranch.\n \n> Unlike the regular extended sha1 expression modifiers such as\n> name~n, name^n, and name^{type}, it does not work with arbitrary\n> object name; it can only work with a refname. Which is similar\n> to the '@{time}' notation we added when we started using\n> ref-log. Strictly speaking these should not belong to the sha1\n> naming layer, but we can have them anyway for the user's\n> convenience.\n\nYes, this makes sense. Branch relations like \"upstream\" is a\nlocal configuration issue, similar to reflogs.\n\nI vote for \"HEAD@up\", short form \"@up\".\n\n"},{"id":"294509","messageId":"200611071153.32840.Josef.Weidendorfer@gmx.de","threadId":"43276","inReplyTo":"20061107065400.GA25737@diana.vm.bytemark.co.uk","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-07T10:53:32Z","receivedAt":"2006-11-07T10:53:32Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 07 November 2006 07:54, you wrote:\n> > IMHO this kind of aliasing is awkward. When you want to start\n> > another topic branch on the remote branch, or want to reference the\n> > remote branch for diffs, you have to explicitly specify\n> > \"remotes/origin/next\", making for more typing.\n> \n> Having more than one local branch for a remote branch is advanced\n> enough that the user should know how to create branches with any name\n> they choose.\n\nBut such an advanced szenario is exactly the reason to introduce\nthese long branch names like \"origin/next\", isn't it?\nWhen a newbie probably never is confronted with this szenario, then\nwhy give him longer branch names per default?\nDo you see the contradiction in this argument?\n\nIMHO it should be the other way around: when an advanced user\ngets this conflict, he knows how to rename the branches by using\nthis more elaborated scheme.\n\nI understand that these long branch names implicity give you information\nabout the upstream (by including the remote shortcut in front),\nbut this information (like all branch attributes) should also be\neasy available with \"git branch --info\" or similar. Especially,\nwhen we introduce shortcuts like \"@up\" (i.e. git-show-ref @up).\n \n> But I do agree that calling it \"origin/next\" the first time you\n> branch, and \"remotes/origin/next\" subsequent times, is nonintuitive.\n> However, this could be solved by the following message being printed\n> the first time:\n> \n> $ git checkout origin/next\n> No local branch \"origin/next\" exists. Creating new local branch\n> \"origin/next\" off of remote branch \"remotes/origin/next\".\n\nMy patch already does something like this.\n\n"},{"id":"296907","messageId":"20061107135609.GA32376@diana.vm.bytemark.co.uk","threadId":"43276","inReplyTo":"200611071153.32840.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-11-07T13:56:09Z","receivedAt":"2006-11-07T13:56:09Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-11-07 11:53:32 +0100, Josef Weidendorfer wrote:\n\n> On Tuesday 07 November 2006 07:54, you wrote:\n>\n> > Having more than one local branch for a remote branch is advanced\n> > enough that the user should know how to create branches with any\n> > name they choose.\n>\n> But such an advanced szenario is exactly the reason to introduce\n> these long branch names like \"origin/next\", isn't it? When a newbie\n> probably never is confronted with this szenario, then why give him\n> longer branch names per default? Do you see the contradiction in\n> this argument?\n\nWell, I see your point. However, forcing users to have to unlearn and\nrelearn when they want to use more of git's power feels wrong. It\nwould present an artificial barrier for users wishing to proceed from\nthe newbie stage.\n\nIt's more important to have simple rules than to make these rules\ngenerate short names. Long names are not conceptually difficult, just\na bit cumbersome at times.\n\n> IMHO it should be the other way around: when an advanced user gets\n> this conflict, he knows how to rename the branches by using this\n> more elaborated scheme.\n\nBut what happens when an unexperienced user gets this conflict for the\nfirst time (having for the first time used two different remotes)?\nYour scheme forces her to learn two new things instead of one,\ncreating the artificial barrier I mentioned above.\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"294202","messageId":"200611071804.43724.Josef.Weidendorfer@gmx.de","threadId":"43276","inReplyTo":"20061107135609.GA32376@diana.vm.bytemark.co.uk","subject":"Re: [PATCH/RFC] Convenient support of remote branches in git-checkout","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-07T17:04:43Z","receivedAt":"2006-11-07T17:04:43Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 07 November 2006 14:56, you wrote:\n> But what happens when an unexperienced user gets this conflict for the\n> first time (having for the first time used two different remotes)?\n> Your scheme forces her to learn two new things instead of one,\n> creating the artificial barrier I mentioned above.\n\nI give the user a warning that she has to specify a branch\nname herself. This does not force her to rename all her branches\nand go with the new naming /, but probably\nmakes her do\n\n repo developer1, branch next => next (magic behavior)\n repo developer2, branch next => next2 (manual specification)\n\nand perhaps rename next to next1 afterwards.\n\nAt least I do not want to type long branch names; most of the\ncloned repos I have do have only one remote. So I would rename\nthe branches names created with the complex magic scheme.\n\nOf course, another way is to be more smart with branch name parsing.\nCurrently, a given name is searched in\n\t.git/\n\t.git/refs/\n\t.git/refs/tags/\n\t.git/refs/heads/\n\t.git/refs/remotes/\n\t.git/refs/remotes/*/HEAD\n\nWhat about adding before remotes\n\t.git/refs/heads//\nand at the end\n\t.git/refs/remotes//\nIe. when on branch \"origin/next\", a given name \"master\" is\nparsed as \"refs/heads/origin/master\" when existing?\nSo the parsing rule is: \"With current branch X and given name Y,\nsearch for a branch as near as possible to X which has Y as\nlast name component\".\n\nThis would match current UI, where you have simple branch names\nlike \"master\" or \"next\".\nWith above rule, you can use \"master\" to refer\nto \"refs/heads/origin/master\" in the complex model,\nand for a read-only remote head \"refs/heads/remotes/origin/next\",\nit is enough to say\n\tgit-checkout next\nto get a new local branch \"refs/heads/origin/next\" created\nto work on.\n\nYou keep the simple UI and still get the perfect overview with\neg. with \"gitk --all\" even in the case where you work on\n10s of remote branches from multiple repository.\n\n"}]}