Re: Case sensitivity on Windows for absolute paths.

[Ricky Clarkson <ricky.clarkson@gmail.com>]

Hi again,

It would be good if git automatically uppercased the drive letter,
yes.  However, I found the real root of my problem.  Git Bash
(msysgit) sets the working directory to c:\foo for programs launched
if the working directory within it is /c/foo.  Like having spaces in
filenames, that just uncovers a whole myriad of small bugs and
oddities in other programs.

For reference, Cygwin doesn't have that problem; cd /cygdrive/c/foo &&
cmd, cmd gets C:\foo as its working directory.

So to make what I wanted work, I just made sure everything msysgit
installed be on the PATH, then ran everything from cmd.

I hope that this helps the next person who experiences this problem.

Thanks,
Ricky.

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1928 706373
Skype: ricky_clarkson
Google Talk: ricky.clarkson@gmail.com
Google Wave: ricky.clarkson@googlewave.com



On 23 April 2010 20:46, Johannes Sixt <j6t@kdbg.org> wrote:
> On Freitag, 23. April 2010, Ricky Clarkson wrote:
>> I noticed that if I have a git repository at C:\foo, and there is a
>> file in there named bar, git add bar works fine, git add C:\foo/bar
>> works fine but git add c:\foo/bar does not.  git reports that the file
>> 'is outside repository'.  Looking at setup.c it seems that string
>> comparisons are being used to determine whether a file is within the
>> repository.
>
> Yes, we should be a bit more liberal when drive letters are compared; they
> should be treated in a case-insensitive manner, but currently we are strict.
>
>> For my purposes I can probably make a Windows build that does it while
>> ignoring the case, but is there a more proper way that git should do
>> it?  I'm not familiar enough with the POSIX file routines to know.
>
> My guess is that it is sufficient that
>
> 1. the internal version of GIT_DIR is recorded with an uppercase drive letter;
>
> 2. normalize_path_copy() upper-cases the drive letter.
>
> Then the comparison in prefix_path() should do the right thing.
>
> -- Hannes
>