* 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).