On Tue, 4 Dec 2012 10:43:32 -0800 (PST)
Jeffrey Marans <jmar...@gmail.com> 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
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.