On Sep 2, 2009, at 2:54 PM, Steven Jenkins wrote: > > Luke Kanies wrote: > ... >>> >>> rake start_feature[events] >> >> I'm a little confused by this syntax -- is it literally >> 'start_feature[events]'? If so, doesn't the shell expand that >> weirdly? Or at least, couldn't it? Is this a rake thing? >> > > You should quote it, but you don't have to. The syntax is a rake > thing. Yes, > it's really ugly and shell-unfriendly. > > However, the shell doesn't expand that weirdly unless you have a > filename that > matches that pattern (i.e., most shells pass along unmatched metachars > unchanged). For example: > > $ ls foo* > ls: cannot access foo*: No such file or directory > $ echo foo[bar] > foo[bar] > $ touch foob > $ echo foo[bar] > foob > > ...
Yeah, but still... As long as this is standard syntax, that was my
main concern.
[...]
>> 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.
>
> 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've also got a 'git-cleanup-branch' script that cleans up things
>> like
>> this by looking through the git history to see if a given commit (as
>> determined by its summary, rather than its commit, since that will
>> change on a rebase) is merged, and if so removes the local and remote
>> branches. 90% of its code is abstracting git into an OO interface,
>> so
>> it makes sense to start using the lib at that point.
>>
>
> Mind sharing your script?
Attached.
--
I have a switch in my apartment... It doesn't do anything. Every once
in a while, I turn it on and off. One day I got a call... It was from
a woman in France... She said, "Cut it out!"
-- Stephen Wright
---------------------------------------------------------------------
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
-~----------~----~----~----~------~----~------~--~---
git-branch-cleanup
Description: Binary data
