| Message ID | pull.54.v2.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Work around case-insensitivity issues with cwd on Windows | expand |
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > Changes since v1: > > * Fixed a grammar mistake in the second commit message. Thanks. I think this matches what I earlier queued on 'pu' with Stephen's typofix squashed in, so we are good already.
Hi Junio, On Wed, 24 Oct 2018, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> > writes: > > > Changes since v1: > > > > * Fixed a grammar mistake in the second commit message. > > Thanks. I think this matches what I earlier queued on 'pu' with > Stephen's typofix squashed in, so we are good already. Perfect. Sorry that I forgot to check. Ciao, Dscho
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > On Wed, 24 Oct 2018, Junio C Hamano wrote: > >> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> >> writes: >> >> > Changes since v1: >> > >> > * Fixed a grammar mistake in the second commit message. >> >> Thanks. I think this matches what I earlier queued on 'pu' with >> Stephen's typofix squashed in, so we are good already. > > Perfect. Sorry that I forgot to check. Thanks for double-checking, and I do appreciate the final version, even if it matches the version I would have in 'pu' if I perfectly followed all what was said in the review thread, as I am not always perfect.
On Windows, file names are recorded case-sensitively, but looked up case-insensitively. Therefore, it is possible to switch to a directory by using incorrect case, e.g. cd documentation will still get you into the Documentation subdirectory. In Powershell, doing so will however report the current directory with the specified spelling rather than the one recorded on disk, and Git will get confused. To remedy that, we fixed this in Git for Windows more than three years ago, and needed only a small fix a couple of months later to accommodate for the diverse scenarios encountered by the many Git for Windows users. Not only to keep the story closer to what happened historically, but also to make it easier to follow, I refrained from squashing these two patches. Side note: the second patch is technically not battle-tested for that long: it uses an API function that requires Windows Vista or later, and we only recently started to clean up Git for Windows' code to drop fallbacks for Windows XP. Read: this code used to load the GetFinalPathNameByHandle() function dynamically, and that is the only difference to the code that has been "battle-tested" for close to three years. Changes since v1: * Fixed a grammar mistake in the second commit message. Anton Serbulov (1): mingw: fix getcwd when the parent directory cannot be queried Johannes Schindelin (1): mingw: ensure `getcwd()` reports the correct case compat/mingw.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 48 insertions(+), 2 deletions(-) base-commit: c4df23f7927d8d00e666a3c8d1b3375f1dc8a3c1 Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-54%2Fdscho%2Fmingw-getcwd-v2 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-54/dscho/mingw-getcwd-v2 Pull-Request: https://github.com/gitgitgadget/git/pull/54 Range-diff vs v1: 1: e13ae2338 = 1: e13ae2338 mingw: ensure `getcwd()` reports the correct case 2: 3e3b1c3b1 ! 2: 87ef9ac63 mingw: fix getcwd when the parent directory cannot be queried @@ -4,7 +4,7 @@ `GetLongPathName()` function may fail when it is unable to query the parent directory of a path component to determine the long name - for that component. It happens, because of it uses `FindFirstFile()` + for that component. It happens, because it uses `FindFirstFile()` function for each next short part of path. The `FindFirstFile()` requires `List Directory` and `Synchronize` desired access for a calling process.