{"thread":{"id":"7622","subject":"git-branch, older repos and more confusion","startedAt":"2007-04-12T04:14:06Z","lastAt":"2007-04-12T06:22:00Z","messageCount":9,"participants":["Martin Langhoff","Jeff King","Sam Vilain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39195","messageId":"46a038f90704112114t520374b2qea4f860575c21bce@mail.gmail.com","threadId":"7622","inReplyTo":null,"subject":"git-branch, older repos and more confusion","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-04-12T04:14:06Z","receivedAt":"2007-04-12T04:14:06Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Thanks to Peff for helping me out earlier with my git-branch usage.\nAlas, I seem to be in trouble again.\n\nMy git tracking repo is still using the .git/remotes/origin\ninfrastructure, and now it turns out I can't seem to do a git-pull and\nthen a git-format-patch of my local 'master' for patches to go on top\nof junio's master. I am using 1.5.1.106.ga32037\n\nI'll get a new checkout, but I'm a bit miffed that this is broken -- I\nwanted to use git-format-patch to migrate unmerged patches to the new\ncheckout.\n\n<rant>\nThis is all a bit confusing, and \"the right way to do it\" is changing\ntoo fast. And with the changes, all the little things that make it\neasy to manage it are lost, and all the wiki pages and documentation\nbits are old and wrong. The simple master/origin scheme works well, is\ndead easy to teach, and has worked well for my team of ~14 developers\nworking on maybe ~40 custom branches. It's pretty safe from errors too\n;-)\n\nAlas - I think support for it seems to be going the away... what I am\nmissing is a clear way to say git-clone <repo>#branch that has the\nsame properties that `cg-clone <repo>#branch` has. Namely, once you\nare done, there are clear names for your \"local tip\" and \"remote tip\",\nand push and pull do the right thing without extra params.\n\ncheers,\n\n\nmartin\n"},{"id":"39196","messageId":"20070412042308.GA22539@coredump.intra.peff.net","threadId":"7622","inReplyTo":"46a038f90704112114t520374b2qea4f860575c21bce@mail.gmail.com","subject":"Re: git-branch, older repos and more confusion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-04-12T04:23:08Z","receivedAt":"2007-04-12T04:23:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 12, 2007 at 04:14:06PM +1200, Martin Langhoff wrote:\n\n> My git tracking repo is still using the .git/remotes/origin\n> infrastructure, and now it turns out I can't seem to do a git-pull and\n> then a git-format-patch of my local 'master' for patches to go on top\n> of junio's master. I am using 1.5.1.106.ga32037\n\nWhat doesn't work? IIRC, you might have some problems with doing a\n'pull' with no parameters, since you don't have the right magic in\n.git/config. Have you tried an explicit \"git-pull origin master\"?\n\n> Alas - I think support for it seems to be going the away... what I am\n> missing is a clear way to say git-clone <repo>#branch that has the\n> same properties that `cg-clone <repo>#branch` has. Namely, once you\n> are done, there are clear names for your \"local tip\" and \"remote tip\",\n> and push and pull do the right thing without extra params.\n\nI don't think there is a way to clone _just_ that branch, but if you're\nOK with fetching all of the branches, then you should be able to do\njust:\n\ngit-clone <repo>\ngit-branch --track branch origin/branch\ngit-checkout branch\n\nYours is 'branch' and remote is 'origin/branch'. If that branch is\nmaster, then I believe git-clone should set you up already (and you can\neven still refer to 'origin', which is a synonym for origin/HEAD).\n\nOr am I not understanding your problem?\n\n-Peff\n"},{"id":"39197","messageId":"461DBBA0.3070609@vilain.net","threadId":"7622","inReplyTo":"20070412042308.GA22539@coredump.intra.peff.net","subject":"Re: git-branch, older repos and more confusion","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-04-12T04:54:56Z","receivedAt":"2007-04-12T04:54:56Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Jeff King wrote:\n>> Alas - I think support for it seems to be going the away... what I am\n>> missing is a clear way to say git-clone <repo>#branch that has the\n>> same properties that `cg-clone <repo>#branch` has. Namely, once you\n>> are done, there are clear names for your \"local tip\" and \"remote tip\",\n>> and push and pull do the right thing without extra params.\n>>     \n>\n> I don't think there is a way to clone _just_ that branch, but if you're\n> OK with fetching all of the branches, then you should be able to do\n> just:\n>\n> git-clone <repo>\n> git-branch --track branch origin/branch\n> git-checkout branch\n>   \n\nYou can;\n\n mkdir moodle\n cd moodle\n git-init\n git-remote add -t mdl-topnz -f origin \\\n    git://git.catalyst.net.nz/moodle.git\n\nBut yes, not as easy as \"cg-clone git://...#branch\"\n\nI sent a patch for 'git remote prune -c' recently that would help in the\ntransition between the two remotes formats.\n\nSam.\n"},{"id":"39198","messageId":"46a038f90704112205g53ab4750s673f449ee40165b4@mail.gmail.com","threadId":"7622","inReplyTo":"20070412042308.GA22539@coredump.intra.peff.net","subject":"Re: git-branch, older repos and more confusion","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-04-12T05:05:24Z","receivedAt":"2007-04-12T05:05:24Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 4/12/07, Jeff King <peff@peff.net> wrote:\n> On Thu, Apr 12, 2007 at 04:14:06PM +1200, Martin Langhoff wrote:\n>\n> > My git tracking repo is still using the .git/remotes/origin\n> > infrastructure, and now it turns out I can't seem to do a git-pull and\n> > then a git-format-patch of my local 'master' for patches to go on top\n> > of junio's master. I am using 1.5.1.106.ga32037\n>\n> What doesn't work? IIRC, you might have some problems with doing a\n> 'pull' with no parameters, since you don't have the right magic in\n> .git/config. Have you tried an explicit \"git-pull origin master\"?\n\nSorry - I should have been clearer here... what I can't seem to do is\ngit-format-patch origin/master..master - but I've resolved that.\n\n> > Alas - I think support for it seems to be going the away... what I am\n> > missing is a clear way to say git-clone <repo>#branch that has the\n> > same properties that `cg-clone <repo>#branch` has. Namely, once you\n> > are done, there are clear names for your \"local tip\" and \"remote tip\",\n> > and push and pull do the right thing without extra params.\n>\n> I don't think there is a way to clone _just_ that branch, but if you're\n> OK with fetching all of the branches, then you should be able to do\n> just:\n>\n> git-clone <repo>\n> git-branch --track branch origin/branch\n> git-checkout branch\n\nTrue - that's the hint you gave me yesterday. It doesn't work on 1.4.x\nor 1.5.0 either. Requires 1.5.1+, which is a bit awkward -- I can (and\nwill) move my team to using this, but we have git installs we don't\ncontrol directly, like external collaborators, remote servers where we\nuse git to manage deployments, etc.\n\nWhich means I'll have to write a little list that goes \"if your git is\nversion X, do this, if it's version Y do that\". :-(\n\n> Yours is 'branch' and remote is 'origin/branch'. If that branch is\n> master, then I believe git-clone should set you up already (and you can\n> even still refer to 'origin', which is a synonym for origin/HEAD).\n>\n> Or am I not understanding your problem?\n\nNo. You're spot on. Using this trick however, a few idioms that used\nto work for us don't quite work anymore.\n\nFor example, creating a new \"custom\" branch on the repo used to be\ntrivial and left us with a setup that was simple and safe. For\nexample, if you wanted to work on a custom v1.9:\n\n - cg-clone <repo>#v1.9-maint mydir\n - cd mydir\n - cg-branch-chg origin <repo>#1.9-clientname\n - cg-push     ## this creates the new head on the repo\n - cg-branch-add v1.9-maint <repo>#v1.9-maint mydir\n\nand from there onwards cg-update / cg-push worked on the custom\nbranch, and cg-update v1.9-maint would merge from the maint branch.\n\nAny hints as to how to run such workflow on v1.5.x?\n\ncheers,\n\n\n\nm\n"},{"id":"39199","messageId":"46a038f90704112206j65af1039hc96be93f723b7c28@mail.gmail.com","threadId":"7622","inReplyTo":"461DBBA0.3070609@vilain.net","subject":"Re: git-branch, older repos and more confusion","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-04-12T05:06:27Z","receivedAt":"2007-04-12T05:06:27Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 4/12/07, Sam Vilain <sam@vilain.net> wrote:\n> I sent a patch for 'git remote prune -c' recently that would help in the\n> transition between the two remotes formats.\n\nGood one. BTW, if you are hacking git-remote, it's missing a \"delete\"\ncommand ;-)\n\n\n\nm\n"},{"id":"39201","messageId":"20070412052118.GA30459@coredump.intra.peff.net","threadId":"7622","inReplyTo":"46a038f90704112205g53ab4750s673f449ee40165b4@mail.gmail.com","subject":"Re: git-branch, older repos and more confusion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-04-12T05:21:18Z","receivedAt":"2007-04-12T05:21:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 12, 2007 at 05:05:24PM +1200, Martin Langhoff wrote:\n\n> Which means I'll have to write a little list that goes \"if your git is\n> version X, do this, if it's version Y do that\". :-(\n\nYes, that is frustrating. If you are just working with master/origin, I\nthink you can get away with it due to the default configuration created,\nbut otherwise I'm not sure it's avoidable. I seem to recall a thread\nabout this a few months ago (between me and Bill Lear, maybe?), but I\ndon't recall that there was any especially good conclusion.\n\n> For example, creating a new \"custom\" branch on the repo used to be\n> trivial and left us with a setup that was simple and safe. For\n> example, if you wanted to work on a custom v1.9:\n> \n> - cg-clone <repo>#v1.9-maint mydir\n> - cd mydir\n> - cg-branch-chg origin <repo>#1.9-clientname\n> - cg-push     ## this creates the new head on the repo\n> - cg-branch-add v1.9-maint <repo>#v1.9-maint mydir\n> \n> and from there onwards cg-update / cg-push worked on the custom\n> branch, and cg-update v1.9-maint would merge from the maint branch.\n> \n> Any hints as to how to run such workflow on v1.5.x?\n\nThis will seem like repetition, but it's like this:\n\n  git-clone <repo> mydir\n  cd mydir\n  git-checkout --track -b v1.9-clientname origin/v1.9-maint\n  git-push origin v1.9-clientname    # to create the new head remotely\n\nWhen you do a git-pull without arguments from the v1.9-clientname\nbranch, it will first do a fetch of origin (grabbing the entire state,\nincluding the v1.9-maint branch) and then merge in origin's v1.9-maint.\n\nWhen you do a push without arguments, it will push every head you have\nin common with origin. Because we pushed the v1.9-clientname branch\nonce, it was created and will be part of subsequent pushes.\n\n-Peff\n"},{"id":"39203","messageId":"46a038f90704112300k3abd66d0nc4372962dbee8616@mail.gmail.com","threadId":"7622","inReplyTo":"20070412052118.GA30459@coredump.intra.peff.net","subject":"Re: git-branch, older repos and more confusion","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-04-12T06:00:30Z","receivedAt":"2007-04-12T06:00:30Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 4/12/07, Jeff King <peff@peff.net> wrote:\n> > Any hints as to how to run such workflow on v1.5.x?\n>\n> This will seem like repetition, but it's like this:\n\nThanks for bearing with me ;-)\n\n>   git-clone <repo> mydir\n>   cd mydir\n>   git-checkout --track -b v1.9-clientname origin/v1.9-maint\n>   git-push origin v1.9-clientname    # to create the new head remotely\n>\n> When you do a git-pull without arguments from the v1.9-clientname\n> branch, it will first do a fetch of origin (grabbing the entire state,\n> including the v1.9-maint branch) and then merge in origin's v1.9-maint.\n\nAlmost what I am after, but not quite. In my Cogito workflow,\ncg-update will by default pull from  v1.9-clientname, which is what\nyou want most of the time (collaborating with other developers on that\nbranch). We do cg-update/cg-push all the time, and cg-update\n<maintbranch> is a less frequent operation.\n\nOn my own I had gotten almost to the same sequence you show above, but\ncouldn't get it right. With what you are showing me now, I'd say\n\n git-clone <repo> mydir\n cd mydir\n git-checkout -b tmpbranch origin/v1.9-maint\n git-push origin v1.9-clientname    # to create the new head remotely\n git-checkout --track -b v1.9-clientname origin/v1.9-clientname\n git-deletebranch tmpbranch # this command doesn't exist!\n\nAnd then git-pull / git-push will \"do the right thing\". And `git-pull\norigin/v1.9-maint` will trigger a fetch & merge.\n\n> When you do a push without arguments, it will push every head you have\n> in common with origin.\n\nThat's interesting!\n\ncheers,\n\n\nm\n"},{"id":"39204","messageId":"46a038f90704112316v4aaa6246s9e07a3af8262b119@mail.gmail.com","threadId":"7622","inReplyTo":"46a038f90704112300k3abd66d0nc4372962dbee8616@mail.gmail.com","subject":"Re: git-branch, older repos and more confusion","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-04-12T06:16:20Z","receivedAt":"2007-04-12T06:16:20Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 4/12/07, Martin Langhoff <martin.langhoff@gmail.com> wrote:\n> On my own I had gotten almost to the same sequence you show above, but\n> couldn't get it right. With what you are showing me now, I'd say\n\nAnd I think I got it sussed out with:\n\n   git-clone <repo> mydir\n   cd mydir\n   git-push origin origin/v1.9-maint:refs/heads/v1.9-clientname\n   git-checkout --track -b v1.9-clientname origin/v1.9-clientname\n\ncheers,\n\n\nmartin\n"},{"id":"39205","messageId":"20070412062200.GA31788@coredump.intra.peff.net","threadId":"7622","inReplyTo":"46a038f90704112316v4aaa6246s9e07a3af8262b119@mail.gmail.com","subject":"Re: git-branch, older repos and more confusion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-04-12T06:22:00Z","receivedAt":"2007-04-12T06:22:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 12, 2007 at 06:16:20PM +1200, Martin Langhoff wrote:\n\n> And I think I got it sussed out with:\n> \n>   git-clone <repo> mydir\n>   cd mydir\n>   git-push origin origin/v1.9-maint:refs/heads/v1.9-clientname\n>   git-checkout --track -b v1.9-clientname origin/v1.9-clientname\n\nOK, I had misunderstood what you wanted. Yes, that should work, though I\nthink you will need to do a 'git-fetch' between your push and checkout.\n\n> And then git-pull / git-push will \"do the right thing\". And `git-pull\n> origin/v1.9-maint` will trigger a fetch & merge.\n\nActually, it should be \"git-pull origin v1.9-maint\". Of course, you've\nbeen fetching origin/v1.9-maint all along when you pull your other\nbranch, so you can do it without touching the network at all: \"git-merge\norigin/v1.9-maint\".\n\n-Peff\n"}]}