{"thread":{"id":"20740","subject":"Newbie / git / gitosis question","startedAt":"2009-08-26T09:27:30Z","lastAt":"2009-08-26T15:56:01Z","messageCount":5,"participants":["Howard Miller","Michael Wookey","Graham Perks","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"121786","messageId":"26ae428a0908260227k7ac6aeden9a4eae7ee95d4d45@mail.gmail.com","threadId":"20740","inReplyTo":null,"subject":"Newbie / git / gitosis question","fromName":"Howard Miller","fromEmail":"howard@e-learndesign.co.uk","sentAt":"2009-08-26T09:27:30Z","receivedAt":"2009-08-26T09:27:30Z","isPatch":false,"sender":{"key":"howard@e-learndesign.co.uk","avatar":"https://gravatar.com/avatar/ddb66c6a4a077e52b823ac5b04f33ab927cb90e2ab1eafedaeba07b1920bb99e?d=mp&s=160"},"body":"I've been working away at Gitosis and it's mostly fair enough but\nthere's one bit that's unclear to me...\n\ngit push origin master:refs/heads/master\n\nWould somebody kindly explain (or point to docs) what\nrefs/heads/master means? How is this different from just 'git push\norigin master' or even 'git push origin master:master'?\n\nAny insights much appreciated.\n"},{"id":"121788","messageId":"d2e97e800908260238p28bd6d27o6377f395df32b03c@mail.gmail.com","threadId":"20740","inReplyTo":"26ae428a0908260227k7ac6aeden9a4eae7ee95d4d45@mail.gmail.com","subject":"Re: Newbie / git / gitosis question","fromName":"Michael Wookey","fromEmail":"michaelwookey@gmail.com","sentAt":"2009-08-26T09:38:35Z","receivedAt":"2009-08-26T09:38:35Z","isPatch":false,"sender":{"key":"michaelwookey@gmail.com","avatar":"https://avatars.githubusercontent.com/u/19476?v=4"},"body":"2009/8/26 Howard Miller :\n> I've been working away at Gitosis and it's mostly fair enough but\n> there's one bit that's unclear to me...\n>\n> git push origin master:refs/heads/master\n>\n> Would somebody kindly explain (or point to docs) what\n> refs/heads/master means? How is this different from just 'git push\n> origin master' or even 'git push origin master:master'?\n>\n> Any insights much appreciated.\n\nYou might find some insight here - http://progit.org/book/ch9-5.html\n"},{"id":"121787","messageId":"26ae428a0908260246p71f16b19y5e9d9d6ed63b61b4@mail.gmail.com","threadId":"20740","inReplyTo":"d2e97e800908260238p28bd6d27o6377f395df32b03c@mail.gmail.com","subject":"Re: Newbie / git / gitosis question","fromName":"Howard Miller","fromEmail":"howard@e-learndesign.co.uk","sentAt":"2009-08-26T09:46:46Z","receivedAt":"2009-08-26T09:46:46Z","isPatch":false,"sender":{"key":"howard@e-learndesign.co.uk","avatar":"https://gravatar.com/avatar/ddb66c6a4a077e52b823ac5b04f33ab927cb90e2ab1eafedaeba07b1920bb99e?d=mp&s=160"},"body":"Mmm...\n\nI think I see what's happening - vaguely - but I'm not sure I understand why!\n\nWhy does gitosis require you to be this specific? Why can't I just do\na 'straight' push?\n\nHoward\n\n2009/8/26 Michael Wookey :\n> 2009/8/26 Howard Miller :\n>> I've been working away at Gitosis and it's mostly fair enough but\n>> there's one bit that's unclear to me...\n>>\n>> git push origin master:refs/heads/master\n>>\n>> Would somebody kindly explain (or point to docs) what\n>> refs/heads/master means? How is this different from just 'git push\n>> origin master' or even 'git push origin master:master'?\n>>\n>> Any insights much appreciated.\n>\n> You might find some insight here - http://progit.org/book/ch9-5.html\n>\n"},{"id":"121793","messageId":"56532891-3669-423A-B5A2-A03F10E9189F@ausperks.net","threadId":"20740","inReplyTo":"26ae428a0908260227k7ac6aeden9a4eae7ee95d4d45@mail.gmail.com","subject":"Re: Newbie / git / gitosis question","fromName":"Graham Perks","fromEmail":"gperks@ausperks.net","sentAt":"2009-08-26T11:54:38Z","receivedAt":"2009-08-26T11:54:38Z","isPatch":false,"sender":{"key":"gperks@ausperks.net","avatar":null},"body":"On Aug 26, 2009, at 4:27 AM, Howard Miller wrote:\n> there's one bit that's unclear to me...\n>\n> git push origin master:refs/heads/master\n>\n> Would somebody kindly explain (or point to docs) what\n> refs/heads/master means?\n\nI wish somehow these refs would be hidden so newbies like me and \neveryone I introduce to git didn't have to know about them. They feel \nlike an \"advanced concept\", some internal syntax that 99% of users \nshouldn't need to know about. When I see a refspec in the help pages \nmy eyes glaze over!\n\nGraham.\n"},{"id":"121809","messageId":"20090826155601.GB32741@coredump.intra.peff.net","threadId":"20740","inReplyTo":"26ae428a0908260227k7ac6aeden9a4eae7ee95d4d45@mail.gmail.com","subject":"Re: Newbie / git / gitosis question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-26T15:56:01Z","receivedAt":"2009-08-26T15:56:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 26, 2009 at 10:27:30AM +0100, Howard Miller wrote:\n\n> I've been working away at Gitosis and it's mostly fair enough but\n> there's one bit that's unclear to me...\n> \n> git push origin master:refs/heads/master\n> \n> Would somebody kindly explain (or point to docs) what\n> refs/heads/master means? How is this different from just 'git push\n> origin master' or even 'git push origin master:master'?\n\nI'll try to explain.\n\nRefs are pointers to commits. In other words, you can think of\n\"refs/heads/master\" as a key pointing to a SHA-1 commit id. The long-ish\nname divides up the namespace for refs.\n\nThere are a few special refs that live outside of the refs/ hierarchy,\nlike HEAD, FETCH_HEAD, MERGE_HEAD, ORIG_HEAD, etc. Normal refs are\ngenerally under refs/.\n\nThe refs/heads/ hierarchy is for branches (they are the \"head\" of a line\nof development). The refs/tags hierarchy is for tags. The refs/remotes\nhierarchy is where we store our local idea of where remote repositories'\nbranches point.\n\nPushing (and fetching) take a \"refspec\": two refs, a source and\ndestination, separated by a colon. So \"git push foo:bar\" means \"look up\nmy local ref 'foo' and update or create the remote ref 'bar' with the\nsame commit\".\n\nEvery ref has a \"full name\" that is much longer than what we often\nsee. We can generally abbreviate because one of the following applies:\n\n 1. We are specifying a name to look up, and there is a set of lookup\n rules. For example, the name \"master\" will be considered as a tag,\n and then as a branch, and then as a remote branch.\n\n The lookup rules are described in \"git help rev-parse\" under the\n section \"Specifying Revisions\".\n\n 2. We are using a name in a context that expects a particular type.\n For example, \"git branch foo\" knows that \"foo\" is a new branch\n name, and so will create the ref as refs/heads/foo. Similarly \"git\n tag foo\" will create refs/tags/foo.\n\n 3. We can infer the type from the other half of a refspec. For\n example, given a local branch \"master\" and a tag \"v1.0\" (and\n neither currently existing on the remote side), we can do:\n\n git push origin master:master v1.0:v1.0\n\n and we know that the \"master\" we create on the remote will be a\n branch, because the local \"master\" is a branch, and similarly the\n \"v1.0\" we create on the remote will be a tag because the local\n \"v1.0\" is a tag.\n\nAnd finally, \"git push\" knows a shorthand for refspecs: a refspec\nwithout a colon is treated as having the same string on both sides. So\n\"master\" is really a shortcut for \"master:master\".\n\nKnowing all of that, let's look at your examples:\n\n A. git push origin master\n\n This is really a syntactic shortcut for \"git push origin\n master:master\".\n\n B. git push origin master:master\n\n The left-hand side of the refspec is looked up locally. In this\n case, it is probably going to be \"refs/heads/master\". The right-hand\n side is looked up on the remote. If it exists (i.e., you are\n updating your branch), it is probably \"refs/heads/master\".\n\n If it doesn't exist on the remote (i.e., you are pushing a new\n branch), then we can infer from the prefix of the left-hand side\n that the right-hand side should also be a branch (i.e., under\n \"refs/heads/\").\n\n So assuming \"master\" is a branch, this is really equivalent to:\n\n git push origin refs/heads/master:refs/heads/master\n\n C. git push origin master:refs/heads/master\n\n If you understood the explanation for (B) above, you will know that\n this is again basically the same thing. :)\n\n However, note that in (B), if the branch is being created on the\n remote, we rely on the \"refspec inference\" rule described earlier.\n This behavior was adopted in git in v1.5.5.2 (commit f8aae120,\n 2008-04-23). So you may still see examples that pre-date this\n feature and recommend using the full ref-name, which should no\n longer be necessary.\n\nHope that helps. Let me know if you need clarification on any of the\nabove.\n\n-Peff\n"}]}