On Sep 2, 2009, at 6:15 PM, Steven Jenkins wrote: > > Luke Kanies wrote: > ... >> [...] >>>> I like the idea of these tasks, but I think it'd be nice if they >>>> made >>>> the corresponding remote setups. E.g., adding something like the >>>> following to the git config: >>>> >>>> [branch "tickets/master/2296"] >>>> remote = luke >>>> merge = refs/heads/tickets/master/2296 >>>> >>>> I think there are git commands to do so. We could easily require a >>>> git config option that specified the default remote, and then set >>>> these up. That way all of the 'git push' stuff works just fine. >>> That would be: >>> >>> git checkout -b tickets/master/2296 luke/tickets/master/2296 >>> >>> so you could specify your start as luke/tickets/master/2296: e.g., >>> >>> rake start_ticket[2296,luke/tickets/master/2296] >> >> This only works if there's already a remote branch, which in most >> cases there isn't. I'm talking about from a clean slate, creating >> the >> local branch and the config necessary to create and sync to a remote >> branch. >> >>> which is awkward. I can change to assume the pattern you show, but >>> two >>> questions on inferring/assuming the remote repo: >>> >>> 1- What is the right remote repo to use as the default? I'm >>> thinking there >>> should be two remotes: default pull and default push. >> >> For development branches? I don't understand why. > > For example, I always push to my own github repo, but seldom pull > from it. I > pull from either the main repo, or (more often) from someone else's > when I'm > collaborating on something. My 'origin' for Puppet is > git://reductivelabs.com/puppet, and I (personally) usually specify > my remote > repo for a push. > > If there's a better workflow, I'm all for it...
Each branch can have a separate remote, so this really shouldn't be a problem - master has origin, and your dev branches have your remote. >>> 2- How do you want to handle that if luke/tickets/master/2296 >>> doesn't already >>> exist? Do you want a failure, or do you want to fall through to >>> master? >> >> See above. You can't just fall back to master, because you'd be >> creating a tracking branch from master, which is not so good. >> > > I believe you're alluding to something like: > > # create a new, empty branch on remote repo 'steven', starting from > 'master' > git push steven master:refs/heads/tickets/master/2296 > > # pull down the new ref > git fetch steven > > # and create the local tracking branch > git checkout --track -b tickets/master/2296 steven/tickets/master/2296 > > Is that what you're thinking? I think it's more like: git checkout -b tickets/master/1234 ...do stuff... git config branch.tickets/master/1234.remote luke # from git-publish- branch git config branch.tickets/master/1234.merge refs/heads/tickets/master/ 1234 git push Not sure this exactly works, but it roughly works for the git-publish- branch script in the repo mentioned earlier in the thread (along with the git-wtf script). -- It's not that I'm afraid to die. I just don't want to be there when it happens. -- Woody Allen --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
