"cannot be used without a working tree." errors

[living180]

Since upgrading to Git for Windows v2.5.2 from v2.5.0, I've been running into fatal: <git-command> cannot be used without a working tree. errors in certain cases. It only seems to occur when the initial command invoked was a git alias. It also does not occur when I use the Git SDK shell (I normally use bash from MSYS - not MSYS2) One way to reproduce it:

• set up rb as an alias for rebase
• run MSYS bash: C:\mingw\msys\1.0\bin\bash.exe --login -i
• on a branch which has diverged from its upstream branch, run git rb

I then get the following output:

First, rewinding head to replay your work on top of it...
fatal: C:\git-sdk-64\mingw64/libexec/git-core/git-am cannot be used without a working tree.

The error results from the fact that when git am invoikes git rev-parse --is-inside-work-tree it incorrectly prints false instead of true. I bisected the issue to f7b4bf2. There are no symlinks involved in my case, so the only change is that normalize_ntpath is now called on dirname before it is passed to _wchdir. The only transformation that normalize_ntpath is actually performing in my case is replacing backlashes with forward slashes. When that transformation is in place, is_inside_dir ends up getting called with a path starting with a lowercase drive letter, while xgetcwd returns a path with an uppercase drive letter, causing dir_inside_of to return -1. However, if I remove the backslash transformation from normalize_ntpath, is_inside_dir gets called with an uppercase drive letter path and everything works fine.

I'm not sure exactly how this needs to be fixed, but I'm happy to help with debugging or with testing patches.

[dscho]

run MSYS bash: C:\mingw\msys\1.0\bin\bash.exe --login -i

Why? Why not the Git Bash?

is_inside_dir ends up getting called with a path starting with a lowercase drive letter

I am almost 100% certain that Git Bash would return a path starting with an upper-case drive letter... But not MSys1 Bash... You could say that Git for Windows 2.x is compatible only with the MSys2 Bash (because it ships with it) but not with an MSys1 Bash...

[living180]

Why? Why not the Git Bash?

Because MSYS works for me? I've tried MSYS2 and have run into some issues, so to this point I've preferred to stick with the old MSYS.

I am almost 100% certain that Git Bash would return a path starting with an upper-case drive letter...

Looking at it some more, what happens is that MSYS Bash invokes git with a CWD starting with a lowercase drive letter, while Git Bash/MSYS2 Bash invoke git with a CWD starting with an uppercase drive letter. If the git command is an alias, the initial git invocation adds GIT_WORK_TREE to the environment. When invoked from MSYS Bash, this GIT_WORK_TREE environment variable will start with a lowercase drive letter. Later on, when sh.exe invokes a secondary git, that git has a CWD starting with an uppercase drive letter, causing a drive letter case mismatch when the value from GIT_WORK_TREE is compared with the current directory.

You could say that Git for Windows 2.x is compatible only with the MSys2 Bash (because it ships with it) but not with an MSys1 Bash...

Except that the installer has an option to add git wrappers to PATH. I would expect that in that case git should work from whatever environment it is invoked from. Granted, the fact that MSYS Bash uses a lowercase drive letter is rather unconventional, but I still view this as a regression in git.

Right now I am attempting to determine why git thinks it needs to set GIT_WORK_TREE when handling aliases, because if GIT_WORK_TREE remains unset, the problem goes away.

[living180]

To answer my last question, commit d95138e. No good way to avoid setting GIT_WORK_TREE without reintroducing the problem fixed by that commit.

[dscho]

Why? Why not the Git Bash?

Because MSYS works for me

Ahem. This ticket is proof to the contrary.

As it is, I have enough on my hands supporting the combination of programs shipped with Git for Windows 2.x, so if you go out of your way not to use it, that is fine, but in that case you should be willing to contribute patches to support your setup, not expect me to support your (very funny) setup in addition to the standard one.

So please read this as an encouragement to work on a patch that ignores the case of the drive letter when determining whether we're inside the working directory or not. I will gladly accept that patch (while I will not gladly accept if you expect others to do that work).

So here is how you go about fixing this:

For starters, you need to install the Git for Windows SDK. This will build you a complete Git for Windows 2.x from scratch.

Then, call git grep "<... the error message you saw ...>" in the SDK's /usr/src/git/ directory to find out where the error message is produced. From there, figure out where the comparison happens, and then try to come up with a way to fix the case-sensitive part about it (maybe depending on a compile flag, or a config setting, or some such).

I will not "abandon" you in this endeavor, so feel free to ask for advice at any point. The best idea in such a case would be to push your current work in progress to a topic branch on GitHub so I (or others) can have a look at it and offer suggestions.

[dscho]

So, @living180 where are we at? Are you going to do something about this bug? Or do I have to close it as a "wontfix"?

[living180]

@dscho: first of all, I recognize that there are countless ungrateful and demanding software users in this world, and I'm sure you've encountered your fair share of them. However, I found your responses in this thread to be unwarantedly arrogant and abrasive. E.g.:

Because MSYS works for me

Ahem. This ticket is proof to the contrary.

Actually, MSYS does work for me. For you to tell me that I am using the incorrect software because of a bug in something else is both laughable and arrogant (replace MSYS with Windows and Git Bash with Linux to see the absurdity of your assertion). The reality is that paths on Windows (not counting the esoteric case of mounting a Linux drive via SMB) are case insensitive. Git for Windows does not currently always cope with this gracefully. I don't fault Git for Windows for this, as it is not a trivial thing to address, especially in a portable manner. But the fact that a bug was tickled in Git for Windows does not mean that some other piece of software is at fault.

As it is, I have enough on my hands supporting the combination of programs shipped with Git for Windows 2.x, so if you go out of your way not to use it, that is fine, but in that case you should be willing to contribute patches to support your setup, not expect me to support your (very funny) setup in addition to the standard one.

That is totally understandable. No one has infinite bandwidth.

So please read this as an encouragement to work on a patch that ignores the case of the drive letter when determining whether we're inside the working directory or not. I will gladly accept that patch (while I will not gladly accept if you expect others to do that work).

It is your parenthetical at the end of the above paragraph that really irks me. Never, in any way, did I imply that I was throwing something over the wall and expecting you to just drop everything and work on it. It is totally fine for you to say that it isn't a sufficient priority for you to invest time in this issue. I get that. But you are actually like I committed an offense by simply filing a bug report. The fact of the matter is that before I created the report, I had already spent at least a couple of hours of my own time to narrow down exactly how to trigger the issue, and then to bisect Git for Windows (including figuring out how to get intermediate steps to compile and link when they lacked Windows-specific fixes) to determine exactly when the issue was introduced. I then spent at least another hour after my initial report to better understand exactly why the issue was happening, which resulted in my second comment above.

I've worked with software projects enough to know that immediately jumping in and trying to code up a patch to an unfamiliar and complex piece of software without understanding all the interactions and rationales is likely to result in discarded work because a different approach would actually be better. Which is exactly why I said:

I'm not sure exactly how this needs to be fixed, but I'm happy to help with debugging or with testing patches.

I suppose I should have also said I would be happy to write a patch given a bit of direction. I apologize that I didn't go that far.</sarcasm> At this point, I frankly don't care what you do with this issue - close it or not. If I have the time to test and implement a fix, I'll create a PR, but please don't wait around for me. There are plenty of other open source projects which I actually enjoy contributing to.

[dscho]

I'm not sure exactly how this needs to be fixed, but I'm happy to help with debugging or with testing patches.

I suppose I should have also said I would be happy to write a patch given a bit of direction.

So here is my suggestion how to go about writing said patch:

1. install the Git for Windows SDK (this will already clone and build Git for Windows).
2. find the code responsible for the "cannot be used without a working tree" message by calling
   sh git grep "cannot be used without a working tree"
3. Follow the code from there, backwards (i.e. find the callers until you are at the code that performs that case-sensitive comparison).
4. Replace the comparison with one that respects core.ignoreCase.
5. Create a Pull Request (or submit it to the Git mailing list right away).

And please accept my apologies for my disrespectful way of communicating with you. I was quite stressed last week, but of course that is no excuse for my interaction with you.

[living180]

Thank you for the quick response and the apology - fully accepted. I probably took things more personally than I needed to as well.

Anyway, thanks for the tip about core.ignoreCase - that's not something I would have thought of. If I get some downtime during $DAYJOB this I'll work to see if I can make some progress on this.

[dscho]

sh git grep "cannot be used without a working tree"

Just out of curiosity, I called this myself and found that there are two matches, but the "is-bare-repository" one is obviously okay, so the culprit is the call to git rev-parse --is-inside-work-tree.

The --is-inside-work-tree option simply calls is_inside_work_tree() and that function is defined here (I found this by using git grep, too).

The is_inside_dir() function simply calls xgetcwd() to obtain the current working directory and then calls dir_inside_of().

As you probably have guessed from that code, the comparison indeed is case-sensitive.

[living180]

Yep, I had also gotten that far. Right now I'm trying one approach for dir_inside_of(), but need to make sure it plays nice with non-ASCII characters. Will update when I have something more.

[dscho]

I got it.