Hi Brian, On Thu, May 24, 2012 at 02:08:18PM +1000, Brian May wrote: > Please allow specifying the destination directory as an optional > command line parameter. I want to be able to use gitpkg from a script > that puts the output in a temp directory, and while I could have the > script query, set, and then reset gitpkg.deb-dir, this gets a bit > messy.
Ok, let's see ... I think we can do what you want fairly easily, but first, let's open a small can of context and history worms so that we're on the same page about the best way to do it ... So as a point of general philosophy, gitpkg has tried fairly hard to avoid having or needing any command line options at all, beyond just the refs to export. The main reason for that is to provide some certainty that exports will be reproducible in the future without having to know (or remember :) a magic incantation of options required to get that right - or to have to litter your source with magic config files (which means it would only be usable with repos, and commits in them, that were made specially for it). No command line options at all is kind of the pinnacle of Easy To Remember And Repeat Correctly. Of the options that can be tweaked via git-config, the general rule for those is that you should still get a sane package of the correct source even if they aren't set, and that different users should be able to set them differently to suit local policy, but still export the same refs from the same repos and get essentially the same thing. You can violate that if you really try, but the aim is to avoid it happening by accident or just by following the path of least resistance. With that said, obviously the option that you're asking for does fall into the 'harmless' if omitted set, and gitpkg _is_ very much intended to be incorporated in higher level automation of people's own making like this. So perhaps the thing we need to resurrect here is allowing your script to set DEB_DIR to the tempdir that you want before calling gitpkg. Which already works: $ gitpkg gitpkg branch [origbranch] If gitpkg is run in a git repo with a single branch specified, then it will do a git-archive export of that branch to the ../deb-packages directory. ... $ DEB_DIR=my_tempdir gitpkg gitpkg branch [origbranch] If gitpkg is run in a git repo with a single branch specified, then it will do a git-archive export of that branch to the my_tempdir directory. ... ^^^^^^^^^^ While the manpage no longer mentions that being an interface that the caller might use, only that it's exported for use by hook scripts, it was a part of the original configuration options back when we were using more traditional dotfiles instead of git-config. And for compatibility during the transition reasons, that is still supported. Somewhat ... The main catch is, if you've also got any of the options that used to be able to be set in a dotfile also configured in git-config, then you'll trip the transition sanity check, and it will bail out telling you that you have mix of old and new config, with a list of git-config commands you can use to convert to the 'new' mechanism. So having your script set DEB_DIR would fall over in that case ... Up until this request, we've mostly focussed on gitpkg providing a shell environment that passes information to the hooks. But it does seem like there is also a valid case for letting higher level scripts set up an environment of information for both gitpkg and any hooks that it might in turn invoke. So we kind of have two 'obvious' options from here, that let us remain command line option free and hinge on small changes to things that are already established mechanisms: - Add new alternative names that let the caller set DEB_DIR (and maybe some other things), but which don't trip the transition check. - Kill off the transition check and let you set these things directly once again. And the latter might actually be a reasonable thing to do at this point. The old config hasn't existed since 2009, and last shipped with Lenny, so we could simply fail out if any old config files do still exist, but otherwise refuse to read from them - and make these options available to wrapper scripts for their configuration use again instead. There's a few more details to think through there, but before I waffle on more thinking out loud about them: does this sound like it would work ok for what you need? Is there anything other than DEB_DIR that you can see your script likely wanting to override to do what it needs to do? Best, Ron -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
