On Friday 2009 January 09 22:46:18 4jxDQ6FQee2H@xxxxxxxxxx wrote: >> You could simply commit after running the perl script. You could >> even commit to a branch so that it's (a little) less likely those >> changes get integrated into master. > >How about this, ran by the post-update hook: > >For the first update: > > - Do a git pull I'm not enitirely sure you want post-update doing the pull. > - Then create a new branch 'working' and checkout > - Apply the patches to 'working' and commit > >This leaves 'working' == 'master^' Actually, it leaves HEAD == working and master == working^. >For subsequent updates: > - Compare the SHA1 hashes for 'working' and 'master^'. > - If they don't match, throw an error and exit > - Assuming they match, checkout 'master' and delete 'working' > - Do a git pull (See above) > - Then create a new branch 'working' and checkout > - Apply the patches to 'working' and commit > > >This would keep the working directory clean and allow future updates to >occur, if no one commits anything to git 'working'. If they did, the >script would exit and prevent the update requiring the developer to >review the commit logs and cherry-pick where necessary. It wouldn't *completely* prevent changes to working as one could "git commit --amend" and still have working^ == master. That said, if developers get creative enough they can probably bypass most measures, at least those based on a hook. A privileged process for updates could stash the expected SHA for master and working somewhere developers can't write. That should prevent even dedicated developers from making unauthorized changes, modulo security/cryptographic exploits. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@xxxxxxxxxxxxxxxxx ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.
