repo, cmd: DROP UNEEDED Win path for chcwd & check for '~' homedir

[ankostis]

• Do not abspath twice when constructing cloned repo.
• Add git.repo.base logger.

According to the TCs, the changes in this PR are OK.
@Byron is there any reason for not deleting this Window-only code-path about changing-cwd?

[codecov-io]

Current coverage is 93.97% (diff: 91.66%)

Merging #529 into master will increase coverage by 0.13%

@@             master       #529   diff @@
==========================================
  Files            63         63          
  Lines          9628       9612    -16   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
- Hits           9035       9033     -2   
+ Misses          593        579    -14   
  Partials          0          0          

Powered by Codecov. Last update 4b84602...cc6529c

[ankostis]

Has already been merged in 8ea7e26 with #530.

[Byron]

It's quite amazing that communicate() actually cannot be trusted or is simply not implemented correctly :/.

[ankostis]

Well, you are quite right - communicate() CAN be trusted.

I did a small experiment of reading a Gbyte, both in PY27 and PY35, and they do not block:

>>> import subprocess as sb
>>> proc=sb.Popen('dd if=/dev/zero bs=1024 count=1000000', bufsize=0, stdin=sb.PIPE, stdout=sb.PIPE, stderr=sb.PIPE)
>>> a,b=proc.communicate()

I don't remember when I got this mistrust for communicate(), maybe when I had tried PY33, or maybe when epxerimenting with interactive processes (like the git.cmd.Git.cat-file persistent command); there the comminicate() is not suitable because it will start consuming streams till the death of the process, but the process is awaiting for more input from python-side before ending, so it's a deadlock.

One or two changes in my windows fixes were under this wrong assumption that communicate() should not be trusted. But mostly I replaced code accessing directly proc.stderr/stdout from the main thread - this is definitely freeze-prone code.

[Byron]

A nice experiment ! It doesn't seem to output both on stdout and stderr though, which might be causing the problem we see. The implementation of communicate looks asynchronous, but who knows what's hidden in the details.

[ankostis]

Even when stdout/stderr is interplexed, communicate() does not block (at least in PY3):

>>> import subprocess as sb
>>> proc = sb.Popen(['python','-c',"import sys\nfor i in range(1000000):\n    print('a'*1024); print('b'*1024, file=sys.stderr)"], stdin=sb.PIPE, stdout=sb.PIPE, stderr=sb.PIPE)
>>> %time a,b=proc.communicate()
Wall time: 48.3 s
>>> len(a), len(b)
(1026000000, 1026000000)

For some "unicode" reason cannot run the above experiment in PY2.

[Byron]

@ankostis This looks like a massive simplification, which in any case is a good thing. Given that Appveyor will alert us of breakage, I think it is fine to go ahead with it.