{"thread":{"id":"39491","subject":"git branch <refspec>","startedAt":"2015-06-02T09:45:47Z","lastAt":"2015-06-02T10:22:31Z","messageCount":2,"participants":["Zenaan Harkness"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"262693","messageId":"CAOsGNSTtWnawxmpL7SByUBZ-XUNdDd5nKNuudGQi-S3BjCHcdg@mail.gmail.com","threadId":"39491","inReplyTo":null,"subject":"git branch <refspec>","fromName":"Zenaan Harkness","fromEmail":"zen@freedbms.net","sentAt":"2015-06-02T09:45:47Z","receivedAt":"2015-06-02T09:45:47Z","isPatch":false,"sender":{"key":"zen@freedbms.net","avatar":null},"body":"<refspec> - git's guilty little secret. Let's milk the guilt.\n\ngit branch <refspec> ought work in a similar way to\ngit fetch <refspec>\n\nOne syntax to rule them all. Or something.\n\nI just learned how git fetch uses refspecs and how this can just as\nwell apply to tags to create \"remote tags\" (refs/rtags/remote_name/*),\nfinally grokking the ridiculously simple yet powerful refspec concept\n- it really is generic.\n\nAnd now combining two remotes such as postgresql and postgresql-xc\n(which share substantial code and parent commits), or (a bit out of\ndate now, but) the openmoko-kernel and linux mainline, becomes\nsimpler/saner when \"inventing\" rtags as explained here:\nhttp://stackoverflow.com/questions/22108391/git-checkout-a-remote-tag\n\nSome remotes in this example:\ngit://git.postgresql.org/git/postgresql.git\nhttps://github.com/postgres-x2/postgres-x2.git\ngit://postgres-xc.git.sourceforge.net/gitroot/postgres-xc/postgres-xc\n\n(rtags also makes it \"reasonable\" to store a few other related repos\nin the one local mirror, even when they don't share a parent commit\n(e.g. postgresql-docs, -website etc) - where git fetch gives a\nfriendly little warning to this effect \"warning: no common commits\".\nGit does after all store content, so it's entirely natural for a\nmirror junkie to store related content in one \"mirror\" repo - where\nthere are no common commits, git could auto parallelize fetch, as long\nas this could be ensured to be not brittle.)\n\nThis indicates some \"rtags\" porcelain might be in order, especially to\ncomplement --mirror (since 1.6.0) and soon \"git checkout --to=path\"\n(2.5.0).\nE.g. git remote rename OLDNAME NEWNAME does not auto rename\nrefs/rtags/OLDNAME/ - thankfully there's a little warning though. Also\nrtags ought be recognized as tags when not fully qualified by path,\nfor git merge <commit-ish> etc - try local tags then also rtags when\nsearching for a tag name.\n\nMy main wishlist though is for some porcelain for \"git branch\n<refspec>\" - to my current mind that would make a lot of sense - learn\none LHS:RHS concept, and apply it all over the place.\n\nThanks for listening,\nZenaan\n"},{"id":"262699","messageId":"CAOsGNSQistVzM5vqueOUku9ZOR5dTOFJEtb8X1VwRezLr692Gw@mail.gmail.com","threadId":"39491","inReplyTo":"CAOsGNSTtWnawxmpL7SByUBZ-XUNdDd5nKNuudGQi-S3BjCHcdg@mail.gmail.com","subject":"Re: git branch <refspec>","fromName":"Zenaan Harkness","fromEmail":"zen@freedbms.net","sentAt":"2015-06-02T10:22:31Z","receivedAt":"2015-06-02T10:22:31Z","isPatch":false,"sender":{"key":"zen@freedbms.net","avatar":null},"body":"On 6/2/15, Zenaan Harkness <zen@freedbms.net> wrote:\n> <refspec> - git's guilty little secret. Let's milk the guilt.\n>\n> git branch <refspec> ought work in a similar way to\n> git fetch <refspec>\n>\n> One syntax to rule them all. Or something.\n>\n> I just learned how git fetch uses refspecs and how this can just as\n> well apply to tags to create \"remote tags\" (refs/rtags/remote_name/*),\n> finally grokking the ridiculously simple yet powerful refspec concept\n> - it really is generic.\n>\n> And now combining two remotes such as postgresql and postgresql-xc\n> (which share substantial code and parent commits), or (a bit out of\n> date now, but) the openmoko-kernel and linux mainline, becomes\n> simpler/saner when \"inventing\" rtags as explained here:\n> http://stackoverflow.com/questions/22108391/git-checkout-a-remote-tag\n\nRegarding this stackoverflow article and \"rtags\", what I'm now doing\nis, for postgresql mainline \"origin\" and postresql-xc \"pgxc\" remotes:\n[remote \"origin\"]\n  url = git://git.postgresql.org/git/postgresql.git\n  fetch = +refs/*:refs/*\n  fetch = +refs/*:refs/remotes/origin/*\n[remote \"pgxc\"]\n  url = https://github.com/postgres-x2/postgres-x2.git\n  fetch = +refs/*:refs/remotes/origin/*\n\nso that origin is my normal --mirror, but also with origin and pgxc\nhaving everything (!) under refs/remotes/$name/*\n\nThis allows for those who want multiple related remotes in the one\nmirror to include 'interesting' refs from each remote in a way that\ndoes not clash, e.g. github's refs/pull/* pull requests.\n\nThis only leads to the \"how to minimize typing without extra\nporcelain\", and of course a symlink here can help:\ncd refs/\nln -s remotes r\n\nor perhaps even better :\nln -s remotes/* .\n\nUsing +refs/*:refs/remotes/origin/*  feels better than e.g.:\nrefs/rtags/origin/*\nrefs/rpull/origin/*\nrefs/rtags/pgxc/*\nrefs/rpull/pgxc/*\nrefs/blah?/origin/*\nrefs/blah?/pgxc/*\nalthogh these forms might simplify porcelain (e.g. tab completion)\nwhich needs to work with all refs of a particular 'type'.\n\nZenaan\n"}]}