git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: Johannes Sixt <j6t@kdbg.org>, Jeff King <peff@peff.net>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Torsten Bögershausen" <tboegi@web.de>,
	git@vger.kernel.org,
	"Johannes Schindelin" <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] t1308: do not get fooled by symbolic links to the source tree
Date: Fri, 3 Jun 2016 11:19:36 +0200	[thread overview]
Message-ID: <57514BA8.7020207@web.de> (raw)
In-Reply-To: <57512980.1070200@kdbg.org>

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:/

  reply	other threads:[~2016-06-03  9:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31 22:15 What's cooking in git.git (May 2016, #09; Tue, 31) Junio C Hamano
2016-06-02 14:01 ` What's cooking in git.git (May 2016, #09; Tue, 31) t1308 broken Torsten Bögershausen
2016-06-02 21:22   ` Junio C Hamano
2016-06-02 21:31     ` Junio C Hamano
2016-06-02 21:39       ` Jeff King
2016-06-02 22:15         ` [PATCH] t1308: do not get fooled by symbolic links to the source tree Junio C Hamano
2016-06-02 23:16           ` Jeff King
2016-06-02 23:23             ` Stefan Beller
2016-06-03  1:07               ` Jeff King
2016-06-03  6:05           ` Johannes Sixt
2016-06-03  6:10             ` Jeff King
2016-06-03  6:53               ` Johannes Sixt
2016-06-03  9:19                 ` Torsten Bögershausen [this message]
2016-07-14 12:35                   ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57514BA8.7020207@web.de \
    --to=tboegi@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).