Kallithea issues archive

Issue #204: git access fails if git_rev_filter has multiple filters

Reported by: M. Murray
State: new
Created on: 2016-04-05 02:11
Updated on: 2016-04-05 03:12

Description

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?

Attachments

Comments

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.