New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initialization of the repo with README file no longer works, after gitolite.conf is auto-updated by Redmine #338

Closed
necramirez opened this Issue Jan 29, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@necramirez

necramirez commented Jan 29, 2015

I followed the instructions here: https://jbox-web.github.io/redmine_git_hosting/configuration/troubleshooting/#initialization-of-the-repo-with-readme-file-does-not-work

However, when I create a new project and repo and Redmine updates gitolite.conf to include that new repo, the config for repo @all disappears.

@n-rodriguez

This comment has been minimized.

Show comment
Hide comment
@n-rodriguez

n-rodriguez Jan 29, 2015

Member

However, when I create a new project and repo and Redmine updates gitolite.conf to include that new repo, the config for repo @ALL disappears.

Weird...

Member

n-rodriguez commented Jan 29, 2015

However, when I create a new project and repo and Redmine updates gitolite.conf to include that new repo, the config for repo @ALL disappears.

Weird...

@n-rodriguez n-rodriguez self-assigned this Jan 29, 2015

@n-rodriguez n-rodriguez added the bug label Jan 29, 2015

@necramirez

This comment has been minimized.

Show comment
Hide comment
@necramirez

necramirez Feb 5, 2015

Since, to add the repo @all config, I have to do it by hand, do you think it's worth making this a new function for the plugin, where the plugin automatically adds that config, whenever Initialization is enabled? :-D

If not, how about changing the docs to suggest the scheme you mention in #341 -- whether or not there will be repos managed outside of Redmine, still create a separate .conf for Redmine and just include that in gitolite.conf? This way, we can add the repo @all config in the main gitolite.conf, without the risk of the plugin overwriting it.

What do you think?

necramirez commented Feb 5, 2015

Since, to add the repo @all config, I have to do it by hand, do you think it's worth making this a new function for the plugin, where the plugin automatically adds that config, whenever Initialization is enabled? :-D

If not, how about changing the docs to suggest the scheme you mention in #341 -- whether or not there will be repos managed outside of Redmine, still create a separate .conf for Redmine and just include that in gitolite.conf? This way, we can add the repo @all config in the main gitolite.conf, without the risk of the plugin overwriting it.

What do you think?

n-rodriguez added a commit that referenced this issue Mar 15, 2015

@n-rodriguez

This comment has been minimized.

Show comment
Hide comment
@n-rodriguez

n-rodriguez Mar 15, 2015

Member

Since, to add the repo @all config, I have to do it by hand, do you think it's worth making this a new function for the plugin, where the plugin automatically adds that config, whenever Initialization is enabled? :-D

Added in commit f294e1f

If not, how about changing the docs to suggest the scheme you mention in #341 -- whether or not there will be repos managed outside of Redmine, still create a separate .conf for Redmine and just include that in gitolite.conf? This way, we can add the repo @all config in the main gitolite.conf, without the risk of the plugin overwriting it.

Actually the @all repository shouldn't disappear after a repository update since modifications on Gitolite file are 'atomic' in that we modify only one repository at a time.

Here the process :

  1. load gitolite.conf file as a GitoliteAdmin object. (Repositories are loaded as GitoliteAdmin::Repository object and GitoliteAdmin has a reference for every one of them)
  2. delete the updated repository from GitoliteAdmin references and regenerate it's configuration
  3. add the new reference and rewrite the gitolite.conf file

So this is really weird that the @all repository disappears from gitolite.conf.

Member

n-rodriguez commented Mar 15, 2015

Since, to add the repo @all config, I have to do it by hand, do you think it's worth making this a new function for the plugin, where the plugin automatically adds that config, whenever Initialization is enabled? :-D

Added in commit f294e1f

If not, how about changing the docs to suggest the scheme you mention in #341 -- whether or not there will be repos managed outside of Redmine, still create a separate .conf for Redmine and just include that in gitolite.conf? This way, we can add the repo @all config in the main gitolite.conf, without the risk of the plugin overwriting it.

Actually the @all repository shouldn't disappear after a repository update since modifications on Gitolite file are 'atomic' in that we modify only one repository at a time.

Here the process :

  1. load gitolite.conf file as a GitoliteAdmin object. (Repositories are loaded as GitoliteAdmin::Repository object and GitoliteAdmin has a reference for every one of them)
  2. delete the updated repository from GitoliteAdmin references and regenerate it's configuration
  3. add the new reference and rewrite the gitolite.conf file

So this is really weird that the @all repository disappears from gitolite.conf.

@n-rodriguez n-rodriguez added this to the v1.0.3 milestone Mar 15, 2015

@necramirez

This comment has been minimized.

Show comment
Hide comment
@necramirez

necramirez Mar 16, 2015

I'll wait for v1.0.3 to be released, before trying this. Our setup is working smoothly right now, except we initialize new repos manually. Wouldn't want to disturb the peace. :-p

In the meantime, I'm going to take your word about commit f294e1f, so feel free to close this issue. :-)

Thanks!

necramirez commented Mar 16, 2015

I'll wait for v1.0.3 to be released, before trying this. Our setup is working smoothly right now, except we initialize new repos manually. Wouldn't want to disturb the peace. :-p

In the meantime, I'm going to take your word about commit f294e1f, so feel free to close this issue. :-)

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment