git submodule update --init breaks if run twice in parallel

git submodule update --init breaks if run twice in parallel

[Germán Ferrero]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
git submodule update --init & git submodule update --init

What did you expect to happen? (Expected behavior)
Something like:
[1] 334031
[1]+ Done git submodule update --init

What happened instead? (Actual behavior)
[1] 333889
error: could not lock config file
/path/to/my/repo/.git/modules/path/to/my/module/config: File exists
fatal: could not set 'core.worktree' to '../../../../modules/path/to/my/module'

What's different between what you expected and what actually happened?
The difference is that in the expected behavior (working up to git
2.44.1 at least),
I got no error by running in parallel git submodules update --init.

Anything else you want to add:
In our scenario git submodules update --init is command run by tasks
that are schedulled
potentially in parallel.

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.46.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /nix/store/izpf49b74i15pcr9708s3xdwyqs4jxwl-bash-5.2p32/bin/bash
libcurl: 8.9.1
OpenSSL: OpenSSL 3.0.14 4 Jun 2024
zlib: 1.3.1
uname: Linux 6.8.4-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.4-2
(2024-04-10T17:36Z) x86_64
compiler info: gnuc: 13.3
libc info: glibc: 2.39
$SHELL (typically, interactive shell):
/nix/store/izpf49b74i15pcr9708s3xdwyqs4jxwl-bash-5.2p32/bin/bash


[Enabled Hooks]


-- 
Germán Francisco Ferrero.

Re: git submodule update --init breaks if run twice in parallel

[Germán Ferrero]

Sorry, it also happens on version 2.44.1, It just seems less likely.
But if you try enough times you will get the same error.

I guess this is just the way it's supposed to work, and there's nothing to fix.

On Wed, Oct 16, 2024 at 10:07 AM Germán Ferrero <ferrero.gf@gmail.com> wrote:
>
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
> git submodule update --init & git submodule update --init
>
> What did you expect to happen? (Expected behavior)
> Something like:
> [1] 334031
> [1]+ Done git submodule update --init
>
> What happened instead? (Actual behavior)
> [1] 333889
> error: could not lock config file
> /path/to/my/repo/.git/modules/path/to/my/module/config: File exists
> fatal: could not set 'core.worktree' to '../../../../modules/path/to/my/module'
>
> What's different between what you expected and what actually happened?
> The difference is that in the expected behavior (working up to git
> 2.44.1 at least),
> I got no error by running in parallel git submodules update --init.
>
> Anything else you want to add:
> In our scenario git submodules update --init is command run by tasks
> that are schedulled
> potentially in parallel.
>
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
>
>
> [System Info]
> git version:
> git version 2.46.0
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /nix/store/izpf49b74i15pcr9708s3xdwyqs4jxwl-bash-5.2p32/bin/bash
> libcurl: 8.9.1
> OpenSSL: OpenSSL 3.0.14 4 Jun 2024
> zlib: 1.3.1
> uname: Linux 6.8.4-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.4-2
> (2024-04-10T17:36Z) x86_64
> compiler info: gnuc: 13.3
> libc info: glibc: 2.39
> $SHELL (typically, interactive shell):
> /nix/store/izpf49b74i15pcr9708s3xdwyqs4jxwl-bash-5.2p32/bin/bash
>
>
> [Enabled Hooks]
>
>
> --
> Germán Francisco Ferrero.



-- 
Germán Francisco Ferrero.

Re: git submodule update --init breaks if run twice in parallel

[Taylor Blau]

On Wed, Oct 16, 2024 at 03:49:02PM -0300, Germán Ferrero wrote:
> Sorry, it also happens on version 2.44.1, It just seems less likely.
> But if you try enough times you will get the same error.
>
> I guess this is just the way it's supposed to work, and there's nothing to fix.

Yeah, I suppose the error message:

> > error: could not lock config file
> > /path/to/my/repo/.git/modules/path/to/my/module/config: File exists
> > fatal: could not set 'core.worktree' to '../../../../modules/path/to/my/module'

could be a little friendlier, but I agree that this appears to be
working as expected.

Thanks,
Taylor