I don't know GhostRed, and the Redmine hook on github is "bogus" (a friend of mine thought hitting the "refresh commits" link in Redmine would cause Redmine to pull from origin, this is not the case and that hook is mostly useless).

I have some repos synced to github through hooks and cronjobs, in the corresponding repos on my server:

1. I pull every so often from github through a cronjob,
2. I have a post receive hook that notifies the ChiliProject installation through a well-formed curl to have ChiliProject update its internal representation of the commits each time someone pushes to the repository,
3. I have a post receive hook that pushes to github.

As 99% of stuff is pushed to my installation rather than github because I use github more as a mirror than anything else, it works ok, if you work mostly on github, it will probably work well too, if you work on both, there might be problems.

I don't have docs on this setup, if you're interested I might try to write some.

Would very much like to see a pertinent current writeup on how to get things working together Felix, thanks. Right now it's mainly just GitHub projects, but at some point I may do something else in addition if it becomes too expensive.

Felix:

I saw the github hook and wondered the same. Unless it runs fetch/pull on the actual local repository it is pretty useless.

George:

We have the site here set to do some syncing.

1. developer pushes to github
2. chiliproject.org server (using cron) runs fetch every 15 minutes
3. when updates are fetched from github, the git hook is run
4. which uses curl to refresh the local repository data

You can see the actual code we are using in my updates at the bottom of #57. Felix also has his version of the sync in there too. Maybe later we could build some of this into ChiliProject itself (e.g. pre-"fetch changesets" command).

Eric Davis

57

This feature request might help automate some of this and "fix" the Github hooks from the server side: #507.

Eric Davis

Any reason not to use the github redmine plugin? I find it works rather well via the post-receive hooks (would think this should work for ChiliProject as well).

Also, glad to know that I'm not the only one seeing problems with GitHub's redmine hook. Kind of pointless, sadly.

This last remark sounds good, however I've attempted this before. Apparently my lack of git experience thus far is causing me the problem in that it reaches the part on: `git remote add origin git@github.com:git_user/project.git` and then fails with "fatal: remote origin already exists."

Could you perhaps clarify things with a more beginner explanation of this perhaps that will explain that we have to create another branch first and that origin is simply a new branch name or such if that is the case? I think this may be the crux of the issue.

Additionally, it appears that we perhaps need to use the http method or do we need to utilize an RSA key with ssh to be able to leverage this? All of these would be good clarifications for a ChiliProject writeup on a succinct method to get this working for CP.

George Plymale wrote:

This last remark sounds good, however I've attempted this before. Apparently my lack of git experience thus far is causing me the problem in that it reaches the part on: `git remote add origin git@github.com:git_user/project.git` and then fails with "fatal: remote origin already exists."

Could you perhaps clarify things with a more beginner explanation of this perhaps that will explain that we have to create another branch first and that origin is simply a new branch name or such if that is the case? I think this may be the crux of the issue.

Which tutorial are you following?

Anyway, back to git basics :-) A git remote is a (as the name suggests) remote repository you have some form of access to, in the backend it's "just" a name you give to the address of a remote repository. With git remote -v, you can see which names are given to which remote address. The origin remote is a little particular in that it is the "default" remote, especially it is the name given to the remote you clone from if you initialize your repository by git clone SOMEURL. The names of those remotes also appear in the full list of branches, for example (if you inspect all branches your repository knows about with git branch -a, you will notice the remote branches are named remotes/REMOTEREPOSITORYNAME/REMOTEBRANCHNAME, those are all branches (or to be exact references) your local repository knows about).

So, this brings us back to your problem. The error "fatal: remote origin already exists." means that there already is a remote named origin in your repository. Have a look at git remote -v to see if origin points to a github URL, if not, you can still add the github URL/repository under a different name, for example github with: git remote add github git@github.com:git_user/project.git.

I'd suggest you read a succinct introduction to git though, as the principle of remotes is a rather central one you'd gain knowing more about :-)

Additionally, it appears that we perhaps need to use the http method or do we need to utilize an RSA key with ssh to be able to leverage this? All of these would be good clarifications for a ChiliProject writeup on a succinct method to get this working for CP.

It doesn't matter what protocol you use as long as the authentication (if required) is configured correctly. In other terms: you can use the http URL, but you'll need to either put your password in the URL or in a ~/.netrc if you need to authenticate, and if you use SSH, you'll either need to do it as "your user" so you can upload your key, or create a (I think github calls them) machine key you can specify for a particular project.

George Plymale wrote:

This last remark sounds good, however I've attempted this before. Apparently my lack of git experience thus far is causing me the problem in that it reaches the part on: `git remote add origin git@github.com:git_user/project.git` and then fails with "fatal: remote origin already exists."

Could you perhaps clarify things with a more beginner explanation of this perhaps that will explain that we have to create another branch first and that origin is simply a new branch name or such if that is the case? I think this may be the crux of the issue.

Additionally, it appears that we perhaps need to use the http method or do we need to utilize an RSA key with ssh to be able to leverage this? All of these would be good clarifications for a ChiliProject writeup on a succinct method to get this working for CP.

All of our main repos are on GitHub (example), so our local redmine-related repos are simple mirrors for the purposes of commit tracking (for others this will of course be inverted). For our redmine setup I basically ran git clone --mirror https://github.com/user/project.git (note the use of a the read-only URL, and creation of a full mirror). We set perms as 0775 (probably could be stricter) and the owner as apache. After adding the above-linked plugin to vendor/plugins, restarting redmine, and setting the GitHub generic post-receive URL correctly, everything in the local redmine repo is pulling from github as expected (even branches).

I'm guessing any Chiliproject/Redmine-based fetch_changeset integration would account for both use cases (GitHub as the primary repo or the mirror, so a local pull or push)?

Added an how-to under HowTo_mirror_your_git_repository_on_Github, probably a little rough at the edges, but should be a good starting point.