* Possible minor bug in Git
@ 2019-01-31 7:01 Angelo Melonas
2019-01-31 7:29 ` Angelo Melonas
0 siblings, 1 reply; 10+ messages in thread
From: Angelo Melonas @ 2019-01-31 7:01 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Possible minor bug in Git
2019-01-31 7:01 Possible minor bug in Git Angelo Melonas
@ 2019-01-31 7:29 ` Angelo Melonas
2019-01-31 20:34 ` Torsten Bögershausen
0 siblings, 1 reply; 10+ messages in thread
From: Angelo Melonas @ 2019-01-31 7:29 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Possible minor bug in Git
2019-01-31 7:29 ` Angelo Melonas
@ 2019-01-31 20:34 ` Torsten Bögershausen
2019-02-01 8:02 ` Angelo Melonas
0 siblings, 1 reply; 10+ messages in thread
From: Torsten Bögershausen @ 2019-01-31 20:34 UTC (permalink / raw)
To: Angelo Melonas; +Cc: git
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>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Possible minor bug in Git
2019-01-31 20:34 ` Torsten Bögershausen
@ 2019-02-01 8:02 ` Angelo Melonas
2019-02-02 6:38 ` Torsten Bögershausen
0 siblings, 1 reply; 10+ messages in thread
From: Angelo Melonas @ 2019-02-01 8:02 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
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>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Possible minor bug in Git
2019-02-01 8:02 ` Angelo Melonas
@ 2019-02-02 6:38 ` Torsten Bögershausen
2019-02-06 22:17 ` Giuseppe Crinò
0 siblings, 1 reply; 10+ messages in thread
From: Torsten Bögershausen @ 2019-02-02 6:38 UTC (permalink / raw)
To: Angelo Melonas; +Cc: git
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 ?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Possible minor bug in Git
2019-02-02 6:38 ` Torsten Bögershausen
@ 2019-02-06 22:17 ` Giuseppe Crinò
2019-02-07 19:41 ` Johannes Schindelin
0 siblings, 1 reply; 10+ messages in thread
From: Giuseppe Crinò @ 2019-02-06 22:17 UTC (permalink / raw)
To: tboegi; +Cc: angelomelonas, git
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Possible minor bug in Git
2019-02-06 22:17 ` Giuseppe Crinò
@ 2019-02-07 19:41 ` Johannes Schindelin
2019-02-08 17:43 ` Torsten Bögershausen
2019-02-09 18:19 ` Philip Oakley
0 siblings, 2 replies; 10+ messages in thread
From: Johannes Schindelin @ 2019-02-07 19:41 UTC (permalink / raw)
To: Giuseppe Crinò; +Cc: tboegi, angelomelonas, git
[-- 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
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Possible minor bug in Git
2019-02-07 19:41 ` Johannes Schindelin
@ 2019-02-08 17:43 ` Torsten Bögershausen
2019-02-09 18:19 ` Philip Oakley
1 sibling, 0 replies; 10+ messages in thread
From: Torsten Bögershausen @ 2019-02-08 17:43 UTC (permalink / raw)
To: Giuseppe Crinò; +Cc: johannes.schindelin, angelomelonas, git
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
+'
+
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: Possible minor bug in Git
2019-02-07 19:41 ` Johannes Schindelin
2019-02-08 17:43 ` Torsten Bögershausen
@ 2019-02-09 18:19 ` Philip Oakley
2019-02-10 22:46 ` Giuseppe Crino'
1 sibling, 1 reply; 10+ messages in thread
From: Philip Oakley @ 2019-02-09 18:19 UTC (permalink / raw)
To: Giuseppe Crinò; +Cc: Johannes Schindelin, tboegi, angelomelonas, git
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Possible minor bug in Git
2019-02-09 18:19 ` Philip Oakley
@ 2019-02-10 22:46 ` Giuseppe Crino'
0 siblings, 0 replies; 10+ messages in thread
From: Giuseppe Crino' @ 2019-02-10 22:46 UTC (permalink / raw)
To: git; +Cc: Philip Oakley, Johannes Schindelin, tboegi, angelomelonas
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-02-10 22:47 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-31 7:01 Possible minor bug in Git Angelo Melonas
2019-01-31 7:29 ` Angelo Melonas
2019-01-31 20:34 ` Torsten Bögershausen
2019-02-01 8:02 ` Angelo Melonas
2019-02-02 6:38 ` Torsten Bögershausen
2019-02-06 22:17 ` Giuseppe Crinò
2019-02-07 19:41 ` Johannes Schindelin
2019-02-08 17:43 ` Torsten Bögershausen
2019-02-09 18:19 ` Philip Oakley
2019-02-10 22:46 ` Giuseppe Crino'
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).