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 ... >> Also, I toyed with using the git-ruby library (http://git.rubyforge.org/ >> ) >> and replacing the shell invocations with Ruby code, but I thought >> that would be more appropriate for a later version. If someone >> would like >> to see that, feel free to let me know (or, better yet, submit >> code..). I was >> also a little hesitant to add another gem dependency. > > I like the idea of using this - it's something we'd probably start to > use a lot more of. > Unfortunately, the last change to the git-ruby package was in 2007; it seems to be unmaintained at this point. If someone knows of a decent git library for Ruby, let me know. ... >> tasks/rake/mail_patches.rake | 35 ---------------- >> 2 files changed, 93 insertions(+), 35 deletions(-) >> create mode 100644 tasks/rake/git_workflow.rake >> delete mode 100644 tasks/rake/mail_patches.rake > > Does the Rakefile automatically load all rake task files, or should > there be a require in here, or what? It seems weird you can move the > mail_patches task without having to change a require. > The Puppet Rakefile has: Dir['tasks/**/*.rake'].each { |t| load t } which just globs up everything. ... >> + >> +# This should be changed as new versions get released >> +...@next_release = "0.26.x" > > We often won't actually know this. E.g., I actually hope the next > release (after 0.25) is 1.0, but we're going to start on the > assumption it'll be 0.26. > Right. That's just a default, and if we don't know it, we can specify that (e.g., change it to a raise or remove it). >> +def find_start(start) >> +# This is a case statement, as we might want to map certain >> +# git tags to starting points that are not currently in git. >> + case start >> + when @next_release: return "master" >> + else return start >> + end >> +end >> + >> +desc "Do git setup to start work on a feature" >> +task :start_feature, [:feature,:branch] do |t, args| > > I take it this is how rake deals with the start_feature[events] syntax? Correct. You basically declare your variables, then put a block to process them. ... > 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] 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. 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? > > 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? Thanks, Steven --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
