git -C has unexpected behaviour

Hi guys,

I ran into some really weird git behaviour today.

My git --version is: git version 2.8.1.windows.1

We have a git repository with a submodule called TestData. The data in there is modified and reset as part of our unit tests.

The submodule is a sub-folder of the git repository called TestData. So the relative path from the git repository to the submodule is .\TestData

If I delete the entire TestData folder and run git -C .\TestData reset --hard

I will get the following error: git : fatal: Cannot change to '.\TestData': No such file or directory This is as expected.

Now, to the unexpected part, which I think is a bug:

If the TestData folder is there, but empty (I deleted all the files), then running

git -C .\TestData reset --hard

will NOT throw me an error but run

git reset --hard

on the git repository (not the submodule in the sub-directory!), without warning, or error. This is easy to reproduce by having an empty .\TestData folder, and just changing any file in your git repository before running

git -C .\TestData reset --hard

and seeing the local file changes gone.

Because of this we have had losses of uncommitted changes a few times now (loosing a few days of work, and getting a bit paranoid), but could never find the root cause for this until today, where I found out that it happens when the TestData directory is empty.

Thank for looking into this, and I am looking forward to hear your opinions about this.

Best Regards, Felix Nairz