I'll rephrase my issue without the extraneous bits. I've a bugzilla server from which I want to send branch manipulation commands to a remote central GIT repository server. The bugzilla/mysql database stored procedure that generates system commands is not the issue.
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. 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. Near as I can tell, you've now removed all the technical hurtles that prevented my migrating a couple of dozen CVS modules with history going back 15 years to GIT. I'm sure there are about 55 developers here who're going to way way happier once that's done. Regarding shell access, /usr/bin/git-shell is exactly what I need. Administrator accounts are different, as is root. Thanks again. Jeff. On Wednesday, December 5, 2012 6:37:56 AM UTC-5, Konstantin Khomoutov wrote: > > On Tue, 4 Dec 2012 10:43:32 -0800 (PST) > Jeffrey Marans <jma...@gmail.com <javascript:>> wrote: > > > I'm working on transitioning about 15 CVS modules to GIT repositories > > and I think I've got a handle on how to translate the cvs triggers to > > make them run on the git origin. > > > > I have to create triggers that run from the bugzilla server against > > the git origin server that will branch from either main or a release > > branch to a bug branch. > > This was difficult with svn, but quite doable without any SVN > > repositories local to the bugzilla server. > > I'm hoping to find out I've made a mistake thinking that isn't > > possible with GIT. > > > > Any ideas on that? > > Could you please try to re-explain your idea without mentioning > Subversion and CVS completely? > > Do I understand you correctly that your bugzilla server is on a > different machine from that one hosting a central Git repository > (what you call "the origin server"), and you want actions done in > bugzilla to modify the Git repository hosted on that another machine? > > If yes, then read ahead. > > In Subversion, the information about branches is only kept (and > manipulated) on the server, and so the Subversion client naturally has > commands to manipulate those branches on the server. > Git client is only able to push and fetch history, updating the > so-called "references" (local, when fetching and remote, when pushing) > which is a generic name for branches and tags. As a special > case, pushing also allows to delete references in remote repos. > That's all the Git protocol is able to do when it comes to branch > manipulation on the remote side. > Hence, if you want to manipulate branches in a remote repository using > nothing but a Git client, you could do this way: > 1) Install a Git client on the bugzilla server. > 2) `git clone --bare` the "blessed" repository from your "Git origin > server". > 3) Each time you need to do something from a bugzilla "trigger", > a) Force-update the local repository doing something like > git fetch origin '+refs/*:refs/*' > This is needed for both servers to have identical ideas about > how the "blessed" repo looks like. > b) Do whatever manipulation is needed, locally. For instance, fork > a branch off the required branch. > c) Push this change to the origin. Say, if your script created a > branch "bug-12345", it has to do > git push origin bug-12345 > > There might be another approach which people for some reason tend to > overlook. If your "Git origin server" can be accessed via SSH, you can > perform any sugrery on the remote repository using nothing but the SSH > client on the bugzilla side as SSH is a *shell.* > The scripting is done either by constructing a string to be passed to > the `ssh` program as its last argument, or as a script (in a string, in > a temporary file, in a here document or whatnot) which is then fed to > the standard input of the `ssh` program. > In either case, the script runs on the remote side, so it has to do > certain setup (like `cd`ing to the Git repository) first and then > perform the requested actions. Or it could just call a pre-made script > on the remote side. > The only tricky part in this approach is setting up automated SSH > access. This setup usually employs authenticating using public keys > (better) or supplying a password to the SSH client using something like > `sshpass` or scripting the whole thing using Expect. > --
