Issue #204: git access fails if git_rev_filter has multiple filters
|Reported by:||M. Murray|
|Created on:||2016-04-05 02:11|
|Updated on:||2016-04-05 03:12|
If git_rev_filter is configured according to the comment in the sample config:
## git rev filter option, --all is the default filter, if you need to ## hide all refs in changelog switch this to --branches --tags git_rev_filter = --branches --tags
pre-existing git-based repositories fail to show and rescan gives error when processing them. I didn't test what happens with a new git repo.
This happens because kallithea/lib/vcs/backends/git/repository.py line 255 includes settings.GIT_REV_FILTER in the options list passed to self.run_git_command
Consequently, because the two options are a single item in the list, they get passed to the git command together as a single string option.
If git_rev_filter is set to --all, there is no error.
One of the error messages I get is:
2016-04-04 17:03:40.910 ERROR [kallithea.lib.vcs.backends.git.repository] Couldn't run git command ( ['/usr/bin/git', '-c', 'core.quotepath=false', 'rev-list', '--branches --tags', '--reverse', '--date -order']). Original error was:Subprocess exited due to an error: usage: git rev-list [OPTION] <commit-id>... [ -- paths... ] limiting output: --max-count=<n>
The solution, I think is to test for this situation in kallithea/lib/vcs/backends/git/repository.py line 134 and split the incoming cmd before appending it to the option list passed to subprocessio.
How shall I submit a patch?
Comment by Mads Kiilerich, on 2016-04-05 03:12
Hmm ... seems plausible!
Thanks for trying to contribute a fix. For contributing, see http://kallithea.readthedocs.org/en/default/contributing.html .
It would be great if we also could get a test for this case ... but I don't know how that would fit into the test suite.