Re: [PATCH] t1308: do not get fooled by symbolic links to the source tree

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]

Hi,

On Fri, 3 Jun 2016, Torsten Bögershausen wrote:

> On 06/03/2016 08:53 AM, Johannes Sixt wrote:
> > 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.
> >
> > -- Hannes
> Compiling 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:/

This issue was not resolved, and now this commit is on `master`...

Ciao,
Dscho