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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021-06-16 at 00:16:06, Rose Kunkel wrote:
> # 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.

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

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux