Re: git -C has unexpected behaviour

From: Stefan Beller <sbeller@google.com>
Date: Nov 4, 2016, 16:10 UTC
Message-ID: <CAGZ79kafn3usjKPPif6yRg1r_zyspWGNqOPLpCeyQwqFKXydwQ@mail.gmail.com>
In-Reply-To: <CADJspfL3zVCPv+mfRM_v4ukUggQkhGH7KB50a+HLPZXZqn1pXw@mail.gmail.com>

On Fri, Nov 4, 2016 at 7:28 AM, Felix Nairz <felix.nairz@gmail.com> wrote:

Show 24 quoted lines

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

Show 5 quoted lines

>
> Thank for looking into this, and I am looking forward to hear your
> opinions about this.
>
> Best Regards, Felix Nairz