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


Reply via email to