Re: [BUG] `git reset --hard` fails with `update = none` submodules

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jun 16, 2021, 00:51 UTC
Message-ID: <YMlLGwScowX8eXeJ@camp.crustytoothpaste.net>
In-Reply-To: <CAKjYmsELpf9r3bAJj_JUHgVegw_7z2KzyuR_6FYYngpC1XmNeg@mail.gmail.com>

On 2021-06-16 at 00:16:06, Rose Kunkel wrote:

Show 10 quoted lines

> # What did you do before the bug happened? (Steps to reproduce your issue)
> 1. Clone a git repository that sets `update = none` in .gitmodules:
> $ git clone --recurse-submodules https://github.com/ubolonton/tree-sitter-langs
> 
> 2. Perform a hard reset:
> $ cd tree-sitter-langs
> $ git reset --hard
> 
> # What did you expect to happen? (Expected behavior)
> The reset should succeed and do nothing.

I think we're in agreement on this. This should be a fresh clone and so a hard reset should change nothing.

Show 6 quoted lines

> # What happened instead? (Actual behavior)
> The reset command fails with
> ```
> fatal: not a git repository: ../../.git/modules/repos/agda
> fatal: could not reset submodule index
> ```

Hmmm, I can't reproduce this behavior.  What I see is this:

  $ git reset --hard
  HEAD is now at 5d362ce Release 0.10.0

I'm running git version 2.32.0.272.g935e593368 on Debian sid (with the experimental packages).

Can you try the clone and run a "git status" command in the repository to see if anything is modified after your clone? Are the submodules checked out when you perform the clone? In my case, I see lines like this:

  Skipping submodule 'repos/agda'

If you're seeing something different, then that might contribute to the different behavior we're seeing.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA