Re: [PATCH] t1308: do not get fooled by symbolic links to the source tree
- From
Torsten Bögershausen <tboegi@web.de>
- Date
- Jun 3, 2016, 09:19 UTC
- Message-ID
- <57514BA8.7020207@web.de>
- In-Reply-To
- <57512980.1070200@kdbg.org>
On 06/03/2016 08:53 AM, Johannes Sixt wrote:
Show 25 quoted lines
> Am 03.06.2016 um 08:10 schrieb Jeff King:
>> On Fri, Jun 03, 2016 at 08:05:56AM +0200, Johannes Sixt wrote:
>>
>>>> - name=$(pwd)/.gitconfig
>>>> + name=$HOME/.gitconfig
>>>
>>> I haven't tested this, yet, but my guess is that this breaks on
>>> Windows:
>>> test-config will produce C:/foo style path, but the updated test would
>>> expect /c/foo style path. Dscho, do you have an idea how to fix this?
>>
>> Hmm. This should come directly from expand_user_path("~/.gitconfig")
>> which prepends the literal contents of the $HOME variable. It does go
>> through convert_slashes() afterwards, but I don't see any other
>> massaging (but I won't be surprised when you tell me there is some that
>> happens behind the scenes).
>
> Yes, it happens behind the scenes: /c/foo absolute paths are a
> convention used by the POSIX emulation layer (MSYS). When bash (an
> MSYS program) runs a non-MSYS program such as git or test-config, it
> converts the /c/foo paths in the environment (and argument list) to
> c:/foo style because the non-MSYS programs do not understand the MSYS
> convention.
>
> -- HannesCompiling pu didn't succed: unix_stream_connect is missing in read_cache.c
(And many more in index-heloer.c)
(I thought that the index-helper is only compiled on systems, which are known to have unix-sockets and other stuff ?)
After patching that out, t1308 fails: -name=/c/ +name=c:/