git command flag parameters seems to perform backwards from spec

[jwir3]

As per the 0.3.1 documentation:

Using git directly
...
Keyword arguments translate to short and long keyword arguments on the commandline. The special notion git.command(flag=True) will create a flag without value like command --flag.

I have a test repo available at https://github.com/jwir3/git-risk/blob/issue-5/src/test/data/testrepo.zip

When I run the following command via the command line:
git merge-base 6a5c7989 6ff49 c2a881d

I get the following result:
deb5eb357ef6677301b629922279cf2221d4a91d

Which should correspond to the command:
repo.git.merge_base(("6a5c79", "6ff49", "c2a881d"))

However, this GitPython command returns:
88f06c9cf2c3bccf3df73a6c2bcb8a34549ef20f

Which is the equivalent result returned when I perform:
git merge-base 6a5c7989 6ff49 c2a881d --octopus

This should be the same as:
repo.git.merge_base(("6a5c79", "6ff49", "c2a881d"), octopus=True)

Running the above command (with the "octopus=True") results in the commit returned from the command line version without the "--octopus" flag (i.e. commit "deb5eb357ef6677301b629922279cf2221d4a91d"). Thus, it seems to me that the flags that are being passed in when using the git command directly are reversed somewhere along the line before sending it to the git subprocess.

[Byron]

That's an interesting one indeed.
What do you see when you execute your test with the GIT_PYTHON_TRACE=full environment variable set ? This would show the exact git commands issued under the hood, including their return values.

[jwir3]

Ugh...

My bad. I had an incorrect commit within the merge-base command within my test. Using GIT_PYTHON_TRACE=full showed me that --octopus was actually getting used. It turned out that the test data I have has the reverse of the two commits with --octopus and without it if I use a different third hash.

Sorry about that.