Possible minor bug in Git

Possible minor bug in Git

[Angelo Melonas]

Good day,

I found a potential bug in Git for Windows. The bug can be reproduced
as follows:

1. Modify a file so that it shows up as "untracked" when executing the
"git status" command.
2. Attempt to "git add" the file, but change the case of a single
letter. The command executes but no warning or error is displayed.
3. Execute "git status" again and it still shows the file as "untracked".

Please let me know if I am mistaken. I also have a screenshot
demonstrating the "bug" which I cannot attach to this email, but which
can be requested.

Have a great day.

Kind regards,
Angelo Melonas

Re: Possible minor bug in Git

[Angelo Melonas]

Just to clarify, I made a mistake above. Instead of "untracked", I
meant "unstaged".
I apologise for the confusion.

On Thu, Jan 31, 2019 at 9:01 AM Angelo Melonas <angelomelonas@gmail.com> wrote:
>
> Good day,
>
> I found a potential bug in Git for Windows. The bug can be reproduced
> as follows:
>
> 1. Modify a file so that it shows up as "untracked" when executing the
> "git status" command.
> 2. Attempt to "git add" the file, but change the case of a single
> letter. The command executes but no warning or error is displayed.
> 3. Execute "git status" again and it still shows the file as "untracked".
>
> Please let me know if I am mistaken. I also have a screenshot
> demonstrating the "bug" which I cannot attach to this email, but which
> can be requested.
>
> Have a great day.
>
> Kind regards,
> Angelo Melonas

Re: Possible minor bug in Git

[Torsten Bögershausen]

On Thu, Jan 31, 2019 at 09:29:28AM +0200, Angelo Melonas wrote:
> Just to clarify, I made a mistake above. Instead of "untracked", I
> meant "unstaged".
> I apologise for the confusion.
>
> On Thu, Jan 31, 2019 at 9:01 AM Angelo Melonas <angelomelonas@gmail.com> wrote:
> >
> > Good day,
> >
> > I found a potential bug in Git for Windows. The bug can be reproduced
> > as follows:
> >
> > 1. Modify a file so that it shows up as "untracked" when executing the
> > "git status" command.
> > 2. Attempt to "git add" the file, but change the case of a single
> > letter. The command executes but no warning or error is displayed.
> > 3. Execute "git status" again and it still shows the file as "untracked".
> >
> > Please let me know if I am mistaken. I also have a screenshot
> > demonstrating the "bug" which I cannot attach to this email, but which
> > can be requested.
> >
> > Have a great day.
> >
> > Kind regards,
> > Angelo Melonas

See the example below, Git tracks AA.txt, so you must run
git add AA.txt

After a commit, you can tell Git that the file was renamed:
git mv AA.txt Aa.txt
(and then a commit)



------------------------------

user@mac:/tmp/tt2> git init
Initialized empty Git repository in /private/tmp/tt2/.git/
user@mac:/tmp/tt2> echo AAA > AA.txt
user@mac:/tmp/tt2> git add AA.txt
user@mac:/tmp/tt2> git commit -m AA.txt
[master (root-commit) f102760] AA.txt
 1 file changed, 1 insertion(+)
  create mode 100644 AA.txt
  user@mac:/tmp/tt2> echo BB >AA.txt
  user@mac:/tmp/tt2> mv AA.txt  Aa.txt
  user@mac:/tmp/tt2> git status
  On branch master
  Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
      (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   AA.txt

no changes added to commit (use "git add" and/or "git commit -a")
user@mac:/tmp/tt2> git add AA.txt
user@mac:/tmp/tt2> git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   AA.txt

user@mac:/tmp/tt2>

Re: Possible minor bug in Git

[Angelo Melonas]

Hi Torsten,

Thank you so much for getting back to me.

Unfortunately, I believe there is a misunderstanding, as I may have
explained what I found to be a possible bug incorrectly.
The file that is originally added (and then later modified) is never
renamed or moved.
As you will see below, when a user attempts to add a file, but with
the incorrect case, the Git CLI responds the same way it would if a
file was correctly added (i.e., by displaying nothing).
However, in the above case, when you enter "git status", you find that
the file was never actually added, and remains unstaged.
A possible solution to this can be a simple error message similar to
attempting to add a file with its name misspelt.

Using your example, I have illustrated this in the text below:

    C:\Example>git init
    Initialized empty Git repository in C:/Example/.git/

    C:\Example>echo AAA > AA.txt

    C:\Example>git add AA.txt

    C:\Example>git commit -m AA.txt
    [master (root-commit) d550af0] AA.txt
     1 file changed, 1 insertion(+)
     create mode 100644 AA.txt

    C:\Example>echo BB > AA.txt

    C:\Example>git status
    On branch master
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git checkout -- <file>..." to discard changes in working directory)

            modified:   AA.txt

    no changes added to commit (use "git add" and/or "git commit -a")

    C:\Example>git add Aa.txt

    C:\Example>git status
    On branch master
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git checkout -- <file>..." to discard changes in working directory)

            modified:   AA.txt

    no changes added to commit (use "git add" and/or "git commit -a")

    C:\Example>git add A.txt
    fatal: pathspec 'A.txt' did not match any files

    C:\Example>git add AA.txt

    C:\Example>git status
    On branch master
    Changes to be committed:
      (use "git reset HEAD <file>..." to unstage)

            modified:   AA.txt

I am looking forward to hearing from you again.

Kind regards,
Angelo Melonas

On Thu, Jan 31, 2019 at 10:34 PM Torsten Bögershausen <tboegi@web.de> wrote:
>
> On Thu, Jan 31, 2019 at 09:29:28AM +0200, Angelo Melonas wrote:
> > Just to clarify, I made a mistake above. Instead of "untracked", I
> > meant "unstaged".
> > I apologise for the confusion.
> >
> > On Thu, Jan 31, 2019 at 9:01 AM Angelo Melonas <angelomelonas@gmail.com> wrote:
> > >
> > > Good day,
> > >
> > > I found a potential bug in Git for Windows. The bug can be reproduced
> > > as follows:
> > >
> > > 1. Modify a file so that it shows up as "untracked" when executing the
> > > "git status" command.
> > > 2. Attempt to "git add" the file, but change the case of a single
> > > letter. The command executes but no warning or error is displayed.
> > > 3. Execute "git status" again and it still shows the file as "untracked".
> > >
> > > Please let me know if I am mistaken. I also have a screenshot
> > > demonstrating the "bug" which I cannot attach to this email, but which
> > > can be requested.
> > >
> > > Have a great day.
> > >
> > > Kind regards,
> > > Angelo Melonas
>
> See the example below, Git tracks AA.txt, so you must run
> git add AA.txt
>
> After a commit, you can tell Git that the file was renamed:
> git mv AA.txt Aa.txt
> (and then a commit)
>
>
>
> ------------------------------
>
> user@mac:/tmp/tt2> git init
> Initialized empty Git repository in /private/tmp/tt2/.git/
> user@mac:/tmp/tt2> echo AAA > AA.txt
> user@mac:/tmp/tt2> git add AA.txt
> user@mac:/tmp/tt2> git commit -m AA.txt
> [master (root-commit) f102760] AA.txt
>  1 file changed, 1 insertion(+)
>   create mode 100644 AA.txt
>   user@mac:/tmp/tt2> echo BB >AA.txt
>   user@mac:/tmp/tt2> mv AA.txt  Aa.txt
>   user@mac:/tmp/tt2> git status
>   On branch master
>   Changes not staged for commit:
>     (use "git add <file>..." to update what will be committed)
>       (use "git checkout -- <file>..." to discard changes in working directory)
>
>         modified:   AA.txt
>
> no changes added to commit (use "git add" and/or "git commit -a")
> user@mac:/tmp/tt2> git add AA.txt
> user@mac:/tmp/tt2> git status
> On branch master
> Changes to be committed:
>   (use "git reset HEAD <file>..." to unstage)
>
>         modified:   AA.txt
>
> user@mac:/tmp/tt2>

Re: Possible minor bug in Git

[Torsten Bögershausen]

On Fri, Feb 01, 2019 at 10:02:50AM +0200, Angelo Melonas wrote:
> Hi Torsten,
>
> Thank you so much for getting back to me.
>
> Unfortunately, I believe there is a misunderstanding, as I may have
> explained what I found to be a possible bug incorrectly.
> The file that is originally added (and then later modified) is never
> renamed or moved.
> As you will see below, when a user attempts to add a file, but with
> the incorrect case, the Git CLI responds the same way it would if a
> file was correctly added (i.e., by displaying nothing).
> However, in the above case, when you enter "git status", you find that
> the file was never actually added, and remains unstaged.
> A possible solution to this can be a simple error message similar to
> attempting to add a file with its name misspelt.
>
> Using your example, I have illustrated this in the text below:
>
>     C:\Example>git init
>     Initialized empty Git repository in C:/Example/.git/
>
>     C:\Example>echo AAA > AA.txt
>
>     C:\Example>git add AA.txt
>
>     C:\Example>git commit -m AA.txt
>     [master (root-commit) d550af0] AA.txt
>      1 file changed, 1 insertion(+)
>      create mode 100644 AA.txt
>
>     C:\Example>echo BB > AA.txt
>
>     C:\Example>git status
>     On branch master
>     Changes not staged for commit:
>       (use "git add <file>..." to update what will be committed)
>       (use "git checkout -- <file>..." to discard changes in working directory)
>
>             modified:   AA.txt
>
>     no changes added to commit (use "git add" and/or "git commit -a")
>
>     C:\Example>git add Aa.txt
>
>     C:\Example>git status
>     On branch master
>     Changes not staged for commit:
>       (use "git add <file>..." to update what will be committed)
>       (use "git checkout -- <file>..." to discard changes in working directory)
>
>             modified:   AA.txt
>
>     no changes added to commit (use "git add" and/or "git commit -a")
>
>     C:\Example>git add A.txt
>     fatal: pathspec 'A.txt' did not match any files
>
>     C:\Example>git add AA.txt
>
>     C:\Example>git status
>     On branch master
>     Changes to be committed:
>       (use "git reset HEAD <file>..." to unstage)
>
>             modified:   AA.txt
>
> I am looking forward to hearing from you again.
>
> Kind regards,
> Angelo Melonas
>

Actually yes, you can call this a minor bug.

Does anybody want to work on it ?
May be as a first-time-Git contribution ?

Re: Possible minor bug in Git

[Giuseppe Crinò]

I wanted to have a look at the bug, and I can correctly reproduce it using version 2.20.1.windows.1.

To start to even think of fixing this bug I need to build the source for Windows, but I got lost on how to do that.

Is it correct that I should cross-compile from a POSIX system (GNU/Linux), using x86_64-w64-mingw32-gcc and Gnulib to produce a static executable?

Am I missing something? How does people here build for Windows?

Giuseppe

Re: Possible minor bug in Git

[Johannes Schindelin]

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

Hi Giuseppe,

On Wed, 6 Feb 2019, Giuseppe Crinò wrote:

> I wanted to have a look at the bug, and I can correctly reproduce it using version 2.20.1.windows.1.
> 
> To start to even think of fixing this bug I need to build the source for Windows, but I got lost on how to do that.

Does this help?

https://github.com/git-for-windows/git/wiki/Building-Git

Ciao,
Johannes

> 
> Is it correct that I should cross-compile from a POSIX system (GNU/Linux), using x86_64-w64-mingw32-gcc and Gnulib to produce a static executable?
> 
> Am I missing something? How does people here build for Windows?
> 
> Giuseppe
> 

Re: Possible minor bug in Git

[Torsten Bögershausen]

On Fri, Feb 08, 2019 at 04:18:23PM +0100, Giuseppe Crinò wrote:
> OK, I successfully built git on Windows (thanks Johannes!) and I'm now able to run it.
>
> As of 9f16cdd I can successfully reproduce the bug.
>
> Interestingly enough, I can reproduce the bug even for /usr/bin/git running inside Windows Subsystem for Linux. Part of the reason might be that both relies on the same lstat() call... (Note: `stat` inside the WSL is case _insensitive_).
>
> Now: what is the expected result for git running inside Windows? Should it die saying "fatal: pathspec ... did not match any files"?
>
> If that's the case, is the following a valid test case?
>
> 	diff --git a/t/t3700-add.sh b/t/t3700-add.sh
> 	index 8ee4fc70ad..fadd7c74f6 100755
> 	--- a/t/t3700-add.sh
> 	+++ b/t/t3700-add.sh
> 	@@ -61,6 +61,11 @@ test_expect_success 'git add: filemode=0 should not get confused by symlink' '
> 		test_mode_in_index 120000 xfoo2
> 	 '
>
> 	+test_expect_success 'git add: pathspec is case-sensitive' '
> 	+       echo new > file &&
> 	+       test_must_fail git add File
> 	+'
> 	+

In general, yes.
There are 2 comments:
This the "echo" line should have no ' ' after the '>':

	echo new >file &&

The other question is,
if we should move that test case into t0050-filesystem.sh,
but that is a matter of taste.

diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index 192c94eccd..b8d6bad97a 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -106,6 +106,11 @@ test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' '
        test "z$(git cat-file blob :$camel)" = z1
	 '

+test_expect_success CASE_INSENSITIVE_FS 'add (with wrong case)' '
+       git reset --hard initial &&
+       test_must_fail git add CAMELCASE
+'
+

Re: Possible minor bug in Git

[Philip Oakley]

Hi Guiseppe,

On 07/02/2019 19:41, Johannes Schindelin wrote:
> Hi Giuseppe,
>
> On Wed, 6 Feb 2019, Giuseppe Crinò wrote:
>
>> I wanted to have a look at the bug, and I can correctly reproduce it using version 2.20.1.windows.1.

Thank you for having a look.

The root cause of the issues will most probably be use of a case 
insensitive file system on Windows (and Mac). There is a configuration 
flag `core.ignoreCase` [1] that is normally auto detected that can be 
used to decide when the checks should be done and advice [2] or warnings 
given.


There are also similar case issues with branch names should you want to 
go that far. In any case you should probably at least cover the full 
utf-8 filenames, not just ascii ones.

>>
>> To start to even think of fixing this bug I need to build the source for Windows, but I got lost on how to do that.
> Does this help?
>
> https://github.com/git-for-windows/git/wiki/Building-Git
>
> Ciao,
> Johannes
>
>> Is it correct that I should cross-compile from a POSIX system (GNU/Linux), using x86_64-w64-mingw32-gcc and Gnulib to produce a static executable?
>>
>> Am I missing something? How does people here build for Windows?
>>
>> Giuseppe

--

Philip

[1] https://git-scm.com/docs/git-config#git-config-coreignoreCase

[2] https://git-scm.com/docs/git-config#git-config-advice

Re: Possible minor bug in Git

[Giuseppe Crino']

Setting `true` as the default for GIT_ICASE_PATHSPECS_ENVIRONMENT, when git is built on a Windows system, solves the bug.

	diff --git a/pathspec.c b/pathspec.c
	index 12c2b322b3..906cf24e3e 100644
	--- a/pathspec.c
	+++ b/pathspec.c
	@@ -237,7 +237,11 @@ static inline int get_icase_global(void)
		static int icase = -1;

		if (icase < 0)
	+       #if defined(GIT_WINDOWS_NATIVE) || defined(__CYGWIN__)
	+               icase = git_env_bool(GIT_ICASE_PATHSPECS_ENVIRONMENT, 1);
	+       #else
			icase = git_env_bool(GIT_ICASE_PATHSPECS_ENVIRONMENT, 0);
	+       #endif

		return icase;
	 }

Unfortunately that fix introduces a regression too, tested in t/t3700-add.sh --- `error out when attempting to add ignored ones but add others`.

I already spent some time to understand why, but got no luck: I have to dive deeper into the source code.

In case I can fix the regression, is changing the default value of that env variable a good solution? Should I change the approach?

Like leveraging core.ignorecase somewhere ...?

On Sat, Feb 09, 2019 at 06:19:11PM +0000, Philip Oakley wrote:
> The root cause of the issues will most probably be use of a case insensitive
> file system on Windows (and Mac). There is a configuration flag
> `core.ignoreCase` [1] that is normally auto detected that can be used to
> decide when the checks should be done and advice [2] or warnings given.

Thanks,

Giuseppe