{"thread":{"id":"43245","subject":"Re: (unknown)","startedAt":"2006-10-25T14:47:20Z","lastAt":"2006-10-26T15:35:35Z","messageCount":14,"participants":["Junio C Hamano","Jakub Narebski","Josef Weidendorfer","Andy Parkins","andyparkins@gmail.com","Karl Hasselström","Linus Torvalds","Shawn Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296417","messageId":"E1Gck2K-0003H4-00@dvr.360vision.com","threadId":"43245","inReplyTo":null,"subject":"(unknown)","fromName":"","fromEmail":"andyparkins@gmail.com","sentAt":"2006-10-25T14:47:20Z","receivedAt":"2006-10-25T14:47:20Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"From cd4366ed4e3f765c00310c35c0eabeccf433acdb Mon Sep 17 00:00:00 2001\nFrom: Andy Parkins <andyparkins@gmail.com>\nDate: Wed, 25 Oct 2006 15:47:19 +0100\nSubject: [PATCH] Use \"up/\" prefix for all the upstream branches\nTo: git@vger.kernel.org\nX-TUID: aba1ff8a0c61615e\nX-UID: 126\nX-Length: 1359\nMIME-Version: 1.0\nContent-Transfer-Encoding: 7bit\nContent-Disposition: inline\nMessage-Id: <200610251547.19208.andyparkins@gmail.com>\n\nTo easily differentiate the read-only upstream branches, from normal branches,\ndefault to cloning them with the prefix \"up/\" added to their branch names.\nThis also abandons the idea of an \"origin\" branch which is now simply\n\"up/master\" and hence removes the special treatment that master was getting.\n(cherry picked from 33d89375652222c41fbf225f1e1c3bfb38b755b2 commit)\nSigned-off-by: Andy Parkins <andyparkins@gmail.com>\n---\nI'm sure this will be an unwanted patch.  However, I really do think it's \nimportant to highlight these upstream branches in some way.  I realise \nrenaming \"origin\" is probably not going to fly, but perhaps it would be okay \nto have at least the non-origin branches prefixed?\n\n git-clone.sh |    4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 3f006d1..ebd93da 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -185,7 +185,7 @@ fi\n \n if test -z \"$origin\"\n then\n-\torigin=origin\n+\torigin=up/master\n fi\n \n # Turn the source into an absolute path if\n@@ -389,7 +389,7 @@ Pull: refs/heads/$head_points_at:$origin\n \t\t\tthen\n \t\t\t\tcontinue\n \t\t\tfi\n-\t\t\techo \"Pull: refs/heads/${name}:$remote_top/${name}\"\n+\t\t\techo \"Pull: refs/heads/${name}:$remote_top/up/${name}\"\n \t\tdone >>\"$GIT_DIR/remotes/$origin\" &&\n \t\tcase \"$use_separate_remote\" in\n \t\tt)\n-- \n1.4.2.3\n\n"},{"id":"294205","messageId":"ehntnv$b1k$1@sea.gmane.org","threadId":"43245","inReplyTo":"E1Gck2K-0003H4-00@dvr.360vision.com","subject":"Re: (unknown)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-25T14:53:14Z","receivedAt":"2006-10-25T14:53:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"andyparkins@gmail.com wrote:\n\n> To easily differentiate the read-only upstream branches, from normal branches,\n> default to cloning them with the prefix \"up/\" added to their branch names.\n> This also abandons the idea of an \"origin\" branch which is now simply\n> \"up/master\" and hence removes the special treatment that master was getting.\n> (cherry picked from 33d89375652222c41fbf225f1e1c3bfb38b755b2 commit)\n> Signed-off-by: Andy Parkins <andyparkins@gmail.com>\n> ---\n> I'm sure this will be an unwanted patch.  However, I really do think it's \n> important to highlight these upstream branches in some way.  I realise \n> renaming \"origin\" is probably not going to fly, but perhaps it would be okay \n> to have at least the non-origin branches prefixed?\n\nCheck if \"git clone --use-separate-remote\" isn't what you want.\n\nAnd please correct mail sending.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298178","messageId":"200610251610.02446.andyparkins@gmail.com","threadId":"43245","inReplyTo":"ehntnv$b1k$1@sea.gmane.org","subject":"Re: (unknown)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-10-25T15:10:02Z","receivedAt":"2006-10-25T15:10:02Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006 October 25 15:53, Jakub Narebski wrote:\n\n> Check if \"git clone --use-separate-remote\" isn't what you want.\n\nI did try that, but then the branches don't appear in git branch.  I still \nlike that they exist.\n\n> And please correct mail sending.\n\nAHHHH!!! I thought I had.  Dagnamit; I think an upgrade in Debian overwrote my \nmanual git-imap-send compile.  The git-imap-send bug was fixed in \ne0b0830726286287744cc9e1a629a534bbe75452, but doesn't seem to have made it \ninto debian yet.\n\nI'm getting so sick of looking like an idiot.\n\nMy apologies to everyone for the constant noise I keep dumping on the list.  I \npromise I'm trying really hard to be good.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"298129","messageId":"20061025153121.GA29291@diana.vm.bytemark.co.uk","threadId":"43245","inReplyTo":"200610251610.02446.andyparkins@gmail.com","subject":"Re: (unknown)","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-10-25T15:31:21Z","receivedAt":"2006-10-25T15:31:21Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-10-25 16:10:02 +0100, Andy Parkins wrote:\n\n> My apologies to everyone for the constant noise I keep dumping on\n> the list. I promise I'm trying really hard to be good.\n\nI always try sending the patch to myself first, since something almost\nalways goes wrong on the first try. This helps against most problems,\nbut certainly not all. :-)\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"297049","messageId":"7vods0b5rk.fsf@assigned-by-dhcp.cox.net","threadId":"43245","inReplyTo":"200610251610.02446.andyparkins@gmail.com","subject":"Re: (unknown)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-25T18:38:07Z","receivedAt":"2006-10-25T18:38:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> writes:\n\n> On Wednesday 2006 October 25 15:53, Jakub Narebski wrote:\n>\n>> Check if \"git clone --use-separate-remote\" isn't what you want.\n>\n> I did try that, but then the branches don't appear in git branch.  I still \n> like that they exist.\n\n\"git branch -r\" perhaps.\n"},{"id":"296403","messageId":"200610252303.07900.andyparkins@gmail.com","threadId":"43245","inReplyTo":"7vods0b5rk.fsf@assigned-by-dhcp.cox.net","subject":"Re: (unknown)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-10-25T22:03:07Z","receivedAt":"2006-10-25T22:03:07Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006, October 25 19:38, Junio C Hamano wrote:\n\n> > I did try that, but then the branches don't appear in git branch.  I\n> > still like that they exist.\n>\n> \"git branch -r\" perhaps.\n\nThat's pretty good.  It makes things like\n\n  git-log remotes/origin/master..master\n\nA bit long winded, but it's certainly what I asked for.\n\nYou guys really have thought of everything.\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"294126","messageId":"7v1wowm46j.fsf@assigned-by-dhcp.cox.net","threadId":"43245","inReplyTo":"200610252303.07900.andyparkins@gmail.com","subject":"Re: (unknown)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-25T22:16:52Z","receivedAt":"2006-10-25T22:16:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> writes:\n\n> On Wednesday 2006, October 25 19:38, Junio C Hamano wrote:\n>\n>> > I did try that, but then the branches don't appear in git branch.  I\n>> > still like that they exist.\n>>\n>> \"git branch -r\" perhaps.\n>\n> That's pretty good.  It makes things like\n>\n>   git-log remotes/origin/master..master\n>\n> A bit long winded, but it's certainly what I asked for.\n\n\"git log remotes/origin..master\" perhaps?\n\nThe point being, remotes/origin when origin is a directory that\nhas HEAD that points at something, it stands for\nremotes/origin/HEAD.\n"},{"id":"298750","messageId":"20061025221659.GC10140@spearce.org","threadId":"43245","inReplyTo":"200610252303.07900.andyparkins@gmail.com","subject":"Re: (unknown)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-25T22:16:59Z","receivedAt":"2006-10-25T22:16:59Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> wrote:\n> On Wednesday 2006, October 25 19:38, Junio C Hamano wrote:\n> \n> > > I did try that, but then the branches don't appear in git branch.  I\n> > > still like that they exist.\n> >\n> > \"git branch -r\" perhaps.\n> \n> That's pretty good.  It makes things like\n> \n>   git-log remotes/origin/master..master\n> \n> A bit long winded, but it's certainly what I asked for.\n> \n> You guys really have thought of everything.\n\nTry the bash completion support in contrib/completion.  If you\nare using the bash shell it does branch name completions for most\ncommands, including both sides of the '..' in log there.  At this\npoint I can't use Git without it.\n\n-- \n"},{"id":"295430","messageId":"7vwt6okpgr.fsf@assigned-by-dhcp.cox.net","threadId":"43245","inReplyTo":"7v1wowm46j.fsf@assigned-by-dhcp.cox.net","subject":"Re: (unknown)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-25T22:20:04Z","receivedAt":"2006-10-25T22:20:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Andy Parkins <andyparkins@gmail.com> writes:\n>\n>> On Wednesday 2006, October 25 19:38, Junio C Hamano wrote:\n>>\n>>> > I did try that, but then the branches don't appear in git branch.  I\n>>> > still like that they exist.\n>>>\n>>> \"git branch -r\" perhaps.\n>>\n>> That's pretty good.  It makes things like\n>>\n>>   git-log remotes/origin/master..master\n>>\n>> A bit long winded, but it's certainly what I asked for.\n>\n> \"git log remotes/origin..master\" perhaps?\n>\n> The point being, remotes/origin when origin is a directory that\n> has HEAD that points at something, it stands for\n> remotes/origin/HEAD.\n\nHeh, I spoke too fast.\n\n\t\"git log origin..master\"\n\nIf you do not have none of .git/origin, .git/refs/origin,\n.git/refs/tags/origin, .git/refs/heads/origin, nor\n.git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is\nwhat \"origin\" means (see get_sha1_basic() in sha1_name.c).\n\n\n"},{"id":"296292","messageId":"200610260814.05957.andyparkins@gmail.com","threadId":"43245","inReplyTo":"7vwt6okpgr.fsf@assigned-by-dhcp.cox.net","subject":"Re: (unknown)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-10-26T07:14:04Z","receivedAt":"2006-10-26T07:14:04Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"\n> > \"git log remotes/origin..master\" perhaps?\n> >\n> > The point being, remotes/origin when origin is a directory that\n> > has HEAD that points at something, it stands for\n> > remotes/origin/HEAD.\n>\n> Heh, I spoke too fast.\n>\n> \t\"git log origin..master\"\n>\n> If you do not have none of .git/origin, .git/refs/origin,\n> .git/refs/tags/origin, .git/refs/heads/origin, nor\n> .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is\n> what \"origin\" means (see get_sha1_basic() in sha1_name.c).\n\nAgain: you guys have thought of everything.\n\nI believe then, that my problem is that I didn't find this written anywhere - \nwould it be useful if I were to write a Documentation/ file about \ncommit-ish/tree-ish that covered these issues?  Have I overlooked the \nexistence of such a file already?\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"298392","messageId":"7vhcxrqynx.fsf_-_@assigned-by-dhcp.cox.net","threadId":"43245","inReplyTo":"200610260814.05957.andyparkins@gmail.com","subject":"[PATCH] Documentation: clarify refname disambiguation rules.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-26T08:17:06Z","receivedAt":"2006-10-26T08:17:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nobody should create ambiguous refs (i.e. have tag \"foobar\" and branch\n\"foobar\" at the same time) that need to be disambiguated with these\nrules to keep sanity, but the rules are there so document them.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n  >> Heh, I spoke too fast.\n  >>\n  >> \t\"git log origin..master\"\n  >>\n  >> If you do not have none of .git/origin, .git/refs/origin,\n  >> .git/refs/tags/origin, .git/refs/heads/origin, nor\n  >> .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is\n  >> what \"origin\" means (see get_sha1_basic() in sha1_name.c).\n\n  Something like this.\n\n Documentation/git-rev-parse.txt |   25 +++++++++++++++++++++----\n 1 files changed, 21 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt\nindex 5d42570..ed938aa 100644\n--- a/Documentation/git-rev-parse.txt\n+++ b/Documentation/git-rev-parse.txt\n@@ -122,14 +122,30 @@ blobs contained in a commit.\n   your repository whose object name starts with dae86e.\n \n * An output from `git-describe`; i.e. a closest tag, followed by a\n-  dash, a 'g', and an abbreviated object name.\n+  dash, a `g`, and an abbreviated object name.\n \n * A symbolic ref name.  E.g. 'master' typically means the commit\n   object referenced by $GIT_DIR/refs/heads/master.  If you\n   happen to have both heads/master and tags/master, you can\n   explicitly say 'heads/master' to tell git which one you mean.\n+  When ambiguous, a `<name>` is disambiguated by taking the\n+  first match in the following rules:\n \n-* A suffix '@' followed by a date specification enclosed in a brace\n+  . if `$GIT_DIR/<name>` exists, that is what you mean (this is usually\n+    useful only for `HEAD`, `FETCH_HEAD` and `MERGE_HEAD`);\n+\n+  . otherwise, `$GIT_DIR/refs/<name>` if exists;\n+\n+  . otherwise, `$GIT_DIR/refs/tags/<name>` if exists;\n+\n+  . otherwise, `$GIT_DIR/refs/heads/<name>` if exists;\n+\n+  . otherwise, `$GIT_DIR/refs/remotes/<name>` if exists;\n+\n+  . otherwise, `$GIT_DIR/refs/remotes/<name>/HEAD` if exists.\n+\n+* A ref followed by the suffix '@' with a date specification\n+  enclosed in a brace\n   pair (e.g. '\\{yesterday\\}', '\\{1 month 2 weeks 3 days 1 hour 1\n   second ago\\}' or '\\{1979-02-26 18:30:00\\}') to specify the value\n   of the ref at a prior point in time.  This suffix may only be\n@@ -146,8 +162,9 @@ blobs contained in a commit.\n * A suffix '{tilde}<n>' to a revision parameter means the commit\n   object that is the <n>th generation grand-parent of the named\n   commit object, following only the first parent.  I.e. rev~3 is\n-  equivalent to rev{caret}{caret}{caret} which is equivalent to\\\n-  rev{caret}1{caret}1{caret}1.\n+  equivalent to rev{caret}{caret}{caret} which is equivalent to\n+  rev{caret}1{caret}1{caret}1.  See below for a illustration of\n+  the usage of this form.\n \n * A suffix '{caret}' followed by an object type name enclosed in\n   brace pair (e.g. `v0.99.8{caret}\\{commit\\}`) means the object\n-- \n1.4.3.3.g43f1\n"},{"id":"298048","messageId":"ehps96$5b2$1@sea.gmane.org","threadId":"43245","inReplyTo":"7vhcxrqynx.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: clarify refname disambiguation rules.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-26T08:40:45Z","receivedAt":"2006-10-26T08:40:45Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> -* A suffix '@' followed by a date specification enclosed in a brace\n[...]\n> +* A ref followed by the suffix '@' with a date specification\n> +  enclosed in a brace\n>    pair (e.g. '\\{yesterday\\}', '\\{1 month 2 weeks 3 days 1 hour 1\n\nThis introduces strange line breaking. Is it only in source?\n\nHere diff didn't produce optimal for review patch, separating changed from\npart and changed to part with large block of added code.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294419","messageId":"200610261522.44433.Josef.Weidendorfer@gmx.de","threadId":"43245","inReplyTo":"7vwt6okpgr.fsf@assigned-by-dhcp.cox.net","subject":"Re: (unknown)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-10-26T13:22:44Z","receivedAt":"2006-10-26T13:22:44Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Thursday 26 October 2006 00:20, Junio C Hamano wrote:\n> Heh, I spoke too fast.\n> \n> \t\"git log origin..master\"\n> \n> If you do not have none of .git/origin\n\nReally? I thought refs are always looked up in \".git/refs\" only?\n\n> , .git/refs/origin, \n> .git/refs/tags/origin, .git/refs/heads/origin, nor\n> .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is\n> what \"origin\" means (see get_sha1_basic() in sha1_name.c).\n\nYes.\n\nHowever, IMHO it really should be a alias to \"remotes/origin/<branch>\",\ndepending on current \"<branch>\" you are on. AFAI can remember,\nwhen implementing it, HEAD was choosen as sha1_name.c should not\ncope with porcelain issues (e.g. getting current branch name).\nIt was the intention to change remotes/origin/HEAD in the porcelain\ncommand before actual use.\n\nIs this still sensible?\n\n"},{"id":"298710","messageId":"Pine.LNX.4.64.0610260825040.3962@g5.osdl.org","threadId":"43245","inReplyTo":"200610261522.44433.Josef.Weidendorfer@gmx.de","subject":"Re: (unknown)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-26T15:35:35Z","receivedAt":"2006-10-26T15:35:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 26 Oct 2006, Josef Weidendorfer wrote:\n\n> On Thursday 26 October 2006 00:20, Junio C Hamano wrote:\n> > Heh, I spoke too fast.\n> > \n> > \t\"git log origin..master\"\n> > \n> > If you do not have none of .git/origin\n> \n> Really? I thought refs are always looked up in \".git/refs\" only?\n\nYes and no.\n\nThe \"iterate over all refs\" code only ever looks in the \"refs\" \nsubdirectory, so when you _list_ refs, they won't ever be shown unless \nthey are there. That affects a lot of programs (like \"git ls-remote\").\n\nAlso, a symlink-ref has to point into \"refs/\" or it is considered invalid.\n\nBut, there are two extra rules:\n\n - \".git/HEAD\" is obviously special, and will show up separately even for \n   things like \"git ls-remote\", so even processes that _list_ things will \n   show it.\n\n - when you do a named lookup, stuff directly in \".git\" will take \n   precedence over EVERYTHING, even if it is never listed. So for example, \n   if you have a branch named HEAD in .git/refs/heads/HEAD, it doesn't \n   matter. Your \".git/HEAD\" will still be looked up first.\n\n   Similarly, other \"special heads\", like ORIG_HEAD or MERGE_HEAD will be \n   looked up in .git, even though they will never be listed by anything.\n\nSo the \"refs/\" requirement is a real requirement for a \"true ref\", but it \nis still overruled by the rule that we have special refs in $GIT_DIR that \nalways take precedence.\n\nThis also means, for example, that you can always give the \"full\" refname \nfor lookup, ie\n\n\tgit-rev-parse refs/heads/master\n\nworks, because that's the \"full path\" from the \".git\" subdirectory. If we \nonly ever looked things up inside \"refs\", you'd have to use \n\"heads/master\".\n\n"}]}