The bugzilla server script is written in perl and I construct command strings of the form ssh $user@$host "cd $dir; $cmd $options > /dev/null 2>&1" Then I use system($command); Thanks for the -e -u; minor nitpicks to you are useful groomings for the rest of us. It'll be my new prefix :)
On Wednesday, December 5, 2012 10:13:44 AM UTC-5, Konstantin Khomoutov wrote: > > On Wed, 5 Dec 2012 05:10:30 -0800 (PST) > Jeffrey Marans <jma...@gmail.com <javascript:>> wrote: > > > I thought the only possible solution was to have a complete set of > > repositories local to the bugzilla server, as per your first > > suggestion. Thanks for pointing out a far more practical method. > > In fact, I suspect the first approach could be made less heavy-weight > using shallow cloning so that each local clone keeps only a minimum > amount of history since your requirements for branching seemingly do > not require forking new branches off anything other but extsting > branches, that is, "history tips". But I have no experience with this > kind of setup so can't really say if it would work or not. > > > I thought that sending ssh commands to the GIT server would not work > > because there's no .git sub-directory and no working tree in each of > > the central repositories. But commands like 'ssh git@git > > "cd /oacis/test; git branch -lf R73_23333_bug R73"' work just fine. > > That is correct. The SSH client has nothing to do with anything local. > Using Git's SSH transport actually just employs the fact SSH provides > both scripting *and* tunnelling, so, say, `git fetch` uses SSH > to connect to the server, authenticate, and spawn `git-upload-pack` > there; it then spawns `git-receive-pack` locally and then those two > processes are made communicate with each other through their standard > I/O streams which got connected via SSH. So it's the local Git process > which actually accesses the Git repository data (under ".git"), not the > SSH client, which knows nothing about Git. The same "trick" is > routinely exploited by tools like rdiff-backup, which connects via SSH > to the client, spawns `rsync` there and another `rsync` locally and > then makes them communicate. > > One minor nitpick about your > 'cd /oacis/test; git branch -lf R73_23333_bug R73"' > script. > The Unix shell is notorious for its strange approach to error handling: > by default, if a command fails, nothing at all happens unless some > other command cares to inspect the return code and do something if > it's not zero or unless a compound command is created using '||' or > '&&'. So, if, for instance, /oacis/test suddenly vanished for whatever > reason or became inaccessible (say, someone messed up its > permission/ownership data) your `cd` command will silently fail and the > shell will happily continue with running the next command. So I would > advise to always start your scripts with the `set -e -u` command, which > switches the shell to the "fail on any error and on access to an unset > variable" mode. This usually makes failures of shell scripts more > sensible to understand and debug. > --
