git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Karsten Blees <karsten.blees@gmail.com>
To: "Duy Nguyen" <pclouds@gmail.com>, "René Scharfe" <l.s.r@web.de>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Bug in get_pwd_cwd() in Windows?
Date: Wed, 23 Jul 2014 14:40:21 +0200	[thread overview]
Message-ID: <53CFAD35.1080604@gmail.com> (raw)
In-Reply-To: <CACsJy8Ch6FvWp-pOOG4-kDVmb+kyav7oromH8EpeEesPj7B9Yg@mail.gmail.com>

Am 23.07.2014 13:53, schrieb Duy Nguyen:
> On Wed, Jul 23, 2014 at 2:35 AM, René Scharfe <l.s.r@web.de> wrote:
>> Am 21.07.2014 16:13, schrieb Duy Nguyen:
>>
>>> This function tests if $PWD is the same as getcwd() using st_dev and
>>> st_ino. But on Windows these fields are always zero
>>> (mingw.c:do_lstat). If cwd is moved away, I think falling back to $PWD
>>> is wrong. I don't understand the use of $PWD in the first place.
>>> 1b9a946 (Use nonrelative paths instead of absolute paths for cloned
>>> repositories - 2008-06-05) does not explain much.
>>
>>
>> The commit message reads:
>>
>>   Particularly for the "alternates" file, if one will be created, we
>>   want a path that doesn't depend on the current directory, but we want
>>   to retain any symlinks in the path as given and any in the user's view
>>   of the current directory when the path was given.
>>
>> The intent of the patch seems to be to prefer $PWD if it points to the same
>> directory as the one returned by getcwd() in order to preserve "the user's
>> view".  That's why it introduces make_nonrelative_path() (now called
>> absolute_path()), in contrast to make_absolute_path() (now called
>> real_path()).
>>
>> I imagine it's useful e.g. if your home is accessed through a symlink:
>>
>>         /home/foo -> /some/boring/mountpoint
>>
>> Then real_path("bar") would give you "/some/boring/mountpoint/bar", while
>> absolute_path("bar") returned "/home/foo/bar".  Not resolving symlinks keeps
>> the path friendly in this case.  And it keeps working even after the user's
>> home is migrated to /a/bigger/partition and /home/foo is updated
>> accordingly.
> 
> If it's saved back, then yes it's useful. And I think that's the case
> in clone.c. I was tempted to remove this code (because it only works
> if you stand at worktree's root dir anyway, else cwd is moved) but I
> guess we can just disable this code on Windows only instead.
> 

It is disabled on Windows as of 7d092adc get_pwd_cwd(): Do not trust st_dev/st_ino blindly

      reply	other threads:[~2014-07-23 12:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21 14:13 Bug in get_pwd_cwd() in Windows? Duy Nguyen
2014-07-22 19:35 ` René Scharfe
2014-07-23 11:53   ` Duy Nguyen
2014-07-23 12:40     ` Karsten Blees [this message]

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=53CFAD35.1080604@gmail.com \
    --to=karsten.blees@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    --cc=pclouds@gmail.com \
    /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).