On Fri, Nov 4, 2016 at 7:28 AM, Felix Nairz <felix.nairz@xxxxxxxxx> wrote: > 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), And "all the files" includes the ".git" file, which git uses to find out if it is in a git repository. So it keeps walking up until it finds a .git file/directory, which is the parent project. Once a git directory is found, the main function of git initializes some data structures, e.g. the "path prefix" inside the repository which would be " .\TestData" in your case. then the actual command is found and run. So what it is doing is: "Suppose you are in the TestData directory of the parent project and then run the command ..." My gut reaction was to propose to check if any GITLINK (submodule) is a prefix of said "path prefix" and then rather initialize and operate on the submodule. However I do not think this is a good idea: * Git wants to be fast and checking if we are in any submodule slows down the common case. * Historically commands in un-initialized or deinitialized submodules behave as if in the parent project. I think if we'd fix this issue, other people would complain as their workflow is harmed. > > 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), * commit early, commit often such that the losses are less than a few days. * do not remove the submodule directory as a whole thing (make sure the .git file is there and not wiped) * instead use "git -C TestData clean -dffx && git -C TestData reset --hard" https://git-scm.com/docs/git-clean > could never find the root cause for this until today, where I found > out that it happens when the TestData directory is empty. I am undecided if it is a bug or a feature. Fixing this as a bug would be a performance penalty. Not fixing it may incur data losses. I dunno. > > Thank for looking into this, and I am looking forward to hear your > opinions about this. > > Best Regards, Felix Nairz