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
> On Wed, 5 Dec 2012 05:10:30 -0800 (PST)
> > 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"'
> 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.