On 2023-12-31 14:30, Stefan Haller wrote:
Currently, git doesn't seem to be very good at handling two concurrent
invocations of git fetch (or git fetch and git pull). This is a problem
because it is common for git clients to run git fetch periodically in
the background. In that case, when you happen to invoke git pull while
such a background fetch is running, an error occurs ("Cannot rebase
onto
multiple branches").
I can reliably reproduce this by doing
$ git fetch&; sleep 0.1; git pull
[1] 42160
[1] + done git fetch
fatal: Cannot rebase onto multiple branches.
The reason for this failure seems to be that both the first fetch and
the fetch that runs as part of the pull append their information to
.git/FETCH_HEAD, so that the information for the current branch ends up
twice in the file.
Do you think git fetch should be made more robust against scenarios
like
this?
I believe a similar issue has been already raised recently, so perhaps
introducing some kind of file-based locking within git itself could be
justified. It would make the things a bit more robust, and would also
improve the overall user experience.
More context: the git client that I'm contributing to (lazygit) used to
guard against this for its own background fetch with a global mutex
that
allowed only one single fetch, pull, or push at a time. This solved the
problem nicely for lazygit's own operations (at the expense of some
lag,
occasionally); and I'm not aware of any reports about failures because
some other git client's background fetch got in the way, so maybe we
don't have to worry about that too much.
However, we now removed that mutex to allow certain parallel fetch
operations to run at the same time, most notably fetching (and
updating)
a branch that is not checked out (by doing "git fetch origin
branch:branch"). It is useful to be able to trigger this for multiple
branches concurrently, and actually this works fine.
But now we have the problem described above, where a pull of the
checked-out branch runs at the same time as a background fetch; this is
not so unlikely, because lazygit triggers the first background fetch at
startup, so invoking the pull command right after starting lazygit is
very likely to fail.
We could re-introduce a mutex and just make it a little less global;
e.g. protect only pull and parameter-less fetch. But fixing it in git
itself seems preferable to me.
Sorry for the wall of text, but I figured giving more context could be
useful.
