Codecov Report

Merging #702 into master will increase coverage by 1.51%.
The diff coverage is 91.93%.

@@            Coverage Diff             @@
##           master     #702      +/-   ##
==========================================
+ Coverage   92.83%   94.35%   +1.51%     
==========================================
  Files          61       61              
  Lines       10152    10136      -16     
==========================================
+ Hits         9425     9564     +139     
+ Misses        727      572     -155

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0a96030...f48d087. Read the comment docs.

Travis is happy now, fighting with windows

my question would be -- did hooks ever work on windows??? or tests were testing only that they "fail to work"? ;)

the last succesful build on appveyor was https://ci.appveyor.com/project/Byron/gitpython/build/1.0.161 -- at that point there where no tests for succesful hooks execution. So AFAIK they never worked, and I am offloading that for future to #703 . In this one I will skip those tests tests to establish a reliable baseline for now

Kudos to tour efforts and happy fighting ;-)

Regarding hooks, at the time of #519 and for some months later all remaining test-cases were passing on Windows, e.g. https://ci.appveyor.com/project/ankostis/gitpython/build/1.0.433
You may read #525 where i explain the trick to artificially pass Appveyor, and use it to mark also the hooks-TCs as permanently failing.

BTW you may check if your recent efforts have fixed some of those long disabled TCs.

@ankostis -- join the "fun"! but I think/hope I am "done"

hooks -- as of https://ci.appveyor.com/project/ankostis/gitpython/build/1.0.433 you reference, there were no test for testing successful execution of a hook on windows .

Thanks for the pointer to HIDE_WINDOWS_KNOWN_ERRORS -- I will use it instead of plain is_win (just will wait for tests to finish or fail to get a baseline ;))

As for the 'check' -- someone should just check if there is a similar to travis allow_failures, if so -- then there could be a dedicated matrix run which would do that for us, without requiring manual messing around... but that later -- for now just want it to get green.

But in the future (after we are green again), it would be nice if no PR was merged if tests fail...

woohoo -- some of the windows environments are green now! rebuilding to see if some spurious one didn't creep in. any immediate clue about what could be wrong in those anaconda windows ones @ankostis ?

ok, @Byron , @ankostis et al, it is ready for the review. I will leave the appveyor crusade for later/someone else ATM (note a handy addition to .appveyor.yml) - at least some environments are in clear there as well, and travis is all green. Would be nice to establish the baseline of passing CI in master.

I think it is not anaconda to blame but rather Cygwin's Git!
Since git-2.8+, I've seen huge problems with joining local paths, causing most of the 16 failures in the last 2 environments.

For instance in git-2.8+ it doesn't even work the command pip install git+https://github.com/foo/bar.git.
I believe it is this problem: http://lists-archives.com/git/894111-cygwin-git-cannot-install-python-packages-with-pip.html

Yikes

pip install git+http scheme failure on cygwin reported as pypa/pip#4895.

Well... would be nice to get it reviewed/merged at this stage of success so that at least some baseline is established back again, and then tackle cygwin in a more dedicated PR ;)

@yarikoptic Thanks so much for hanging into this! Especially your crusade to get the windows CI green is particularly brave!! @ankostis certainly has a tale to tell there, too!
I am merging this as it already is getting us some steps towards a somewhat sane Christmas release :D! Full disclaimer: I am on vacation now to the end of the year, and intend to get my inbox empty and spend the time it takes.
@yarikoptic @ankostis I understand I was the bottleneck for the upcoming release, and can't even promise betterment. However, if you are not yet able to cut a release on your own, but would like to, I am happily assigning you the rights needed and add your GPG signature keys to the ones officially endorsed by this repository. Just let me know, and we will make it happen.

Thanks @Byron , I hope you will have a nice (and productive in all regards) vacation!
Here is my primary key, (public portion) should be available from public servers

pub   rsa4096/A2DE235062DA33FA 2010-06-07 Yaroslav Halchenko (Yarik) <yoh@onerussian.com>
 Primary key fingerprint: C5B9 05F0 E8D9 FD96 68FF  366F A2DE 2350 62DA 33FA

I usually (for other projects) "tag -s" releases locally, push the tags, create release out of them on github

I am yarikoptic on pypi

@yarikoptic Thanks - I added you to the list of maintainers on PyPi and your key to the release-verification-key.asc, so you should be able to make your own signed releases from now on. Just to stay in training, I would like to do v2.1.8 though :).

oh yeah, I would prefer not to release unless I really have to ;) so I am ok to stay in training for as long as it could be ;-)