All of lore.kernel.org
 help / color / mirror / Atom feed
* Case sensitivity on Windows for absolute paths.
@ 2010-04-23 14:12 Ricky Clarkson
  2010-04-23 19:46 ` Johannes Sixt
  0 siblings, 1 reply; 5+ messages in thread
From: Ricky Clarkson @ 2010-04-23 14:12 UTC (permalink / raw)
  To: git

Hi,

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.

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.

A separate tool, maven, is what specifies it as lowercase, otherwise I
would obviously just write C: instead of c: myself.  I think I know
how to fix that so it uses relative paths, and will look into that,
but it would be good to have git do the right thing too.

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Case sensitivity on Windows for absolute paths.
  2010-04-23 14:12 Case sensitivity on Windows for absolute paths Ricky Clarkson
@ 2010-04-23 19:46 ` Johannes Sixt
  2010-04-25  7:33   ` Ricky Clarkson
  0 siblings, 1 reply; 5+ messages in thread
From: Johannes Sixt @ 2010-04-23 19:46 UTC (permalink / raw)
  To: Ricky Clarkson; +Cc: git

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Case sensitivity on Windows for absolute paths.
  2010-04-23 19:46 ` Johannes Sixt
@ 2010-04-25  7:33   ` Ricky Clarkson
  2010-04-25 18:08     ` Johannes Sixt
  0 siblings, 1 reply; 5+ messages in thread
From: Ricky Clarkson @ 2010-04-25  7:33 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: git

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
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Case sensitivity on Windows for absolute paths.
  2010-04-25  7:33   ` Ricky Clarkson
@ 2010-04-25 18:08     ` Johannes Sixt
  2010-04-25 18:47       ` Ricky Clarkson
  0 siblings, 1 reply; 5+ messages in thread
From: Johannes Sixt @ 2010-04-25 18:08 UTC (permalink / raw)
  To: Ricky Clarkson; +Cc: git

On Sonntag, 25. April 2010, Ricky Clarkson wrote:
> 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.

I don't understand what you mean. Git Bash cannot influence whether git sees 
the drive letter in the working directory in uppercase or lowercase. Unless 
by "working directory" you mean something else than what getcwd() returns.

-- Hannes

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Case sensitivity on Windows for absolute paths.
  2010-04-25 18:08     ` Johannes Sixt
@ 2010-04-25 18:47       ` Ricky Clarkson
  0 siblings, 0 replies; 5+ messages in thread
From: Ricky Clarkson @ 2010-04-25 18:47 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: git

Hi Johannes,

$ cd /c/uk-org-netvu/

Ricky@RICKY-XP /c/uk-org-netvu (trunk)
$ cmd
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

c:\uk-org-netvu>

If I run cmd via Start -> Run, then the prompt shows C:\uk-org-netvu>

I also verified this using the Scala interpreter, printing out
System.getProperty("user.dir"), which varied similarly in case
depending on whether I started it from cmd or from Git Bash.

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 25 April 2010 19:08, Johannes Sixt <j6t@kdbg.org> wrote:
> On Sonntag, 25. April 2010, Ricky Clarkson wrote:
>> 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.
>
> I don't understand what you mean. Git Bash cannot influence whether git sees
> the drive letter in the working directory in uppercase or lowercase. Unless
> by "working directory" you mean something else than what getcwd() returns.
>
> -- Hannes
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-04-25 18:50 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-23 14:12 Case sensitivity on Windows for absolute paths Ricky Clarkson
2010-04-23 19:46 ` Johannes Sixt
2010-04-25  7:33   ` Ricky Clarkson
2010-04-25 18:08     ` Johannes Sixt
2010-04-25 18:47       ` Ricky Clarkson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.