Gitlab and Redmine –

centosgitgitlabredmine

I'm looking to get Redmine integration with Gitlab 6.0 working.

gitlab.yml:

    issues_tracker:
       redmine:

        project_url: "http://issues.myserver.com/projects/:issues_tracker_id"
        issues_url: "http://issues.myserver.com/issues/:id"
        new_issue_url: "http://issues.myserver.com/projects/:issues_tracker_id/issues/new"

However, I run into problems and get the following below:

We're sorry, but something went wrong message in the browser
production.log only has the message Connecting to database specified by database.yml

If I comment out issues_url and new_issue_url, Gitlab works, but the Gitlab continues to use the "base" issue tracker.

In gitlab.yml, redmine: has no effect.

Any suggestions?

Best Answer

It's correct configuration:

  ## External issues trackers
  issues_tracker:
    redmine:
      project_url: "http://domain.com/projects/:issues_tracker_id"
      issues_url: "http://domain.com/issues/:id"
      new_issue_url: "http://domain.com/projects/:issues_tracker_id/issues/new"

If you show a copy-paste code part from your config - I can imagine that you misjudge the gaps (not erased once before redmine:)

Related Solutions

Git – the difference between ‘git pull’ and ‘git fetch’

In the simplest terms, git pull does a git fetch followed by a git merge.

You can do a git fetch at any time to update your remote-tracking branches under refs/remotes/<remote>/. This operation never changes any of your own local branches under refs/heads, and is safe to do without changing your working copy. I have even heard of people running git fetch periodically in a cron job in the background (although I wouldn't recommend doing this).

A git pull is what you would do to bring a local branch up-to-date with its remote version, while also updating your other remote-tracking branches.

From the Git documentation for git pull:

In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

Git – Difference between “git add -A” and “git add .”

This answer only applies to Git version 1.x. For Git version 2.x, see other answers.

Summary:

git add -A stages all changes
git add . stages new files and modifications, without deletions (on the current directory and its subdirectories).
git add -u stages modifications and deletions, without new files

Detail:

git add -A is equivalent to git add .; git add -u.

The important point about git add . is that it looks at the working tree and adds all those paths to the staged changes if they are either changed or are new and not ignored, it does not stage any 'rm' actions.

git add -u looks at all the already tracked files and stages the changes to those files if they are different or if they have been removed. It does not add any new files, it only stages changes to already tracked files.

git add -A is a handy shortcut for doing both of those.

You can test the differences out with something like this (note that for Git version 2.x your output for git add . git status will be different):

git init
echo Change me > change-me
echo Delete me > delete-me
git add change-me delete-me
git commit -m initial

echo OK >> change-me
rm delete-me
echo Add me > add-me

git status
# Changed but not updated:
#   modified:   change-me
#   deleted:    delete-me
# Untracked files:
#   add-me

git add .
git status

# Changes to be committed:
#   new file:   add-me
#   modified:   change-me
# Changed but not updated:
#   deleted:    delete-me

git reset

git add -u
git status

# Changes to be committed:
#   modified:   change-me
#   deleted:    delete-me
# Untracked files:
#   add-me

git reset

git add -A
git status

# Changes to be committed:
#   new file:   add-me
#   modified:   change-me
#   deleted:    delete-me

Best Answer

Related Solutions

Git – the difference between ‘git pull’ and ‘git fetch’

Git – Difference between “git add -A” and “git add .”

Related Topic