Re: Git fetch bug in git 2.21+ "Could not access submodule '%s'"

From: Paolo Pettinato (ppettina) <ppettina@cisco.com>
Date: Aug 14, 2019, 17:03 UTC
Message-ID: <5a58b0eb-0690-c445-dbfd-bd4c5b614629@cisco.com>
In-Reply-To: <xmqqpnl766pj.fsf@gitster-ct.c.googlers.com>

Thanks for the reply!

On 14/08/2019 17:40, Junio C Hamano wrote:

Show 5 quoted lines

>   Why is the user mucking with
> that directory in the first place, and isn't the flagging of the
> situation as an error, done with 26f80ccf ("submodule: migrate
> get_next_submodule to use repository structs", 2018-11-28), a
> bugfix?  If not, why not?

Not sure if you're implying here that this is not a bug; I'd say that:

- Mucking about with a folder that's supposed to contain a submodule is 
not something that a lot of people do (and we worked around the issue), 
and people shouldn't do that, but...

- ... regardless, I believe that "git fetch" shouldn't particularly care 
about the state of the current working directory. I didn't ask it to do 
anything with the submodules, nor have I initialised them. In my 
(limited) knowledge of git, I'd expect git fetch to do its magic 
entirely between the remote and the .git folder.

Our use case was for a submodule containing encrypted secrets; and the mucking about was stubbing out those secrets in a test build without fetching/decrypting them.

It's arguable whether this should be fixed or not; less arguable that we could use a better error message and consistency (1st execution fails, 2nd does not).