Your change looks good - and to get things done I would probably have ended up with a similar solution.

Something I am wondering about is whether we should break support for git pre 1.7 which didn't yet have the --progress flag. Probably that wouldn't be such a good idea, and a prior check to repo.git.version() could help to fix this.

Something I don't like about git.version() yet is that it would call a command every time and return a string that needs to be parsed manually. Instead the method could be implemented on the git command type itself to cache the result, and return parsed information, something like:

def version(self):
    res = get_git_version_output()
    return parse_res_into_tuple()

which could return a tuple with all version integers, like (1,7,3,2).

What do you think ?

I've tried implementing something like what you suggested. I'm not sure what version the --progress flag was introduced in, though -- I just put down 1.7.0.0 as a guess.

Also, I don't have earlier versions on my system and it would be a pain to install them, so I haven't really tested whether the code works when git.version >= (1,7,0,0) returns False. In principle it should work, though...

I tried running nosetests but I couldn't seem to get it to work (even without those commits I made.) I get like 96 errors and 1 failure. Are the tests supposed to be broken, or am I doing it wrong?

Also fixed up some indentation in the previous commit (spaces -> tabs).

The tests are supposed to run, except for two which will require a git-daemon to run (the error message would tell you what to do though).

Besides I just noticed that its probably not a good idea to override git.version directly, as this breaks code for everyone who wanted to use the 'old' version as git.version(). Hence I suggest it to be renamed to version_info, which resembles sys.version_info.

Once you could verify the tests are still working, especially the push/pull tests which use the git-daemon, I will have a look and see which version introduced --progress, in order to set the version to compare to correctly.

Most of the errors are AttributeErrors saying that various objects have no attribute called rorepo. Any idea what might be the cause of that?

Actually I have no idea. I know that the rorepo attribute is created on the base type for all test cases, and on my recent checkout of master it works without an issue.
rorepo is setup during the setUpAll classmethods if I remember correctly. If there would not be called, there was no rorepo. Maybe it is nose acting up ? I use nose version 0.10.4.

Hmm. I switched to your version of nose but the problem remains.. just to make sure I am getting things right: to run the tests, I just need to run nosetests from the root of the project directory tree, right?

Yes, it will do from the root or from the git subdirectory.
You could run it with the --pdb flag, which will drop you into a debugger on the first error. This way you could investigate the type you have and maybe find out more.
The rorepo variable is assigned in git/test/lib/helper.py (search for "rorepo =") - probably nosetest doesn't call the initialization for some reason.

Is it possible for the tests to be run on just your end? I really can't get it to work on my box.

Ok, will do. I might not get to it too soon, as I am actually applying plenty of changes in another branch which will clearly collide with these changes here.

Nonetheless I try to maintain master in the meanwhile, so lets see when I get to it.
Thanks for your efforts !

Alright then. I've renamed version to version_info like you suggested. Sorry I couldn't help more!

I have implemented the contents of this pull request and pushed the changes to the new 0.3 branch. This is to indicate that GitPython 0.3 reached the end of its life and is in maintenance mode. A proper release of 0.3 will follow.

Master now moved on to the latest stable development, which will be 0.4 one day. As master was reset, you will have to reset your local master as well.

Thanks for your participation,
Sebastian