This option allows to disable users from changing their username.
This is very usefull in environments using strong internal authentication methods like ldap, pam or shibboleth.
You can allow users to change theyr username in these environments, but then new users (users loging in first time) is blocked from gitlab is her username exists.
error is that ```enabled ||= true``` always evaluates to true.
Change all initialization of bool settings to use the same syntax:
```setting = true if setting.nil?```
The tasks gitlab:env:info mixes user and group, and presume as a group 'git'.
However, gitolite group name can be anything.
That patch add the git group name in the config,
and check gitolite.ssh_user group against git.group
(which defaults to 'git', as before this patch, if undefined).
M config/gitlab.yml.example:
Add 'group' in 'git' section
Mention default value for the two extra settings
M lib/tasks/gitlab/check.rake:
Check that gitolite.ssh_user *group* is the one defined in git.group.
Make sure to default to 'git' as the expected group
if said group is undefined in the config.
Note: uses a more complete regexp for the group detection
(the group can start, end or be in the middle or the list of groups
of gitolite.ssh_user)
M: config/initializers/1_settings.rb:
Add default values for gitolite.group and gitlab.user
Should no longer freak out when omniauth settings aren't present in
gitlab.yml. People who aren't using it shouldn't even have to put a
'false' entry in their config for it (and probably wouldn't, after an
upgrade).
of 'gitlab.yml'.
gitlabhq\config\initializers\1_settings.rb looks for
'gitolite_admin_uri' in the 'git' section of 'gitlab.yml'
Actually, that setting is in the 'git_host' section.
If not fixed, the 'gitolite_admin_uri' would always be equals to
'git@localhost:gitolite-admin', even if the administrator wants
to have another user than 'git' in charge of that repo.
