Re: Concurrent fetch commands

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 3, 2024, 22:10 UTC
Message-ID: <xmqqwmsq83v3.fsf@gitster.g>
In-Reply-To: <ZZWOBObBmLW9Nid6@nand.local>

Taylor Blau <me@ttaylorr.com> writes:

> ... I suppose the answer is that they expect
> concurrent fetches to be tolerated, but that the contents of FETCH_HEAD
> (and of course the remote references) are consistent at the end of all
> of the fetches.

What does it mean to be "consistent" in this case, though? For the controlled form of multiple fetches performed by "git fetch --all", the answer is probably "as if we fetched sequentially from these remotes, one by one, and concatenated what these individual fetch invocations left in FETCH_HEAD". But for an uncontrolled background fetch IDE and others perform behind user's back, it is unclear what it means, or for that matter, it is dubious if there is a reasonable definition for the word.

Folks who invented "git maintenance" designed their "prefetch" task to perform the best practice, without interfering any foreground fetches by not touching FETCH_HEAD and the remote-tracking branches.

Nobody brought up the latter so far on this discussion thread, but mucking with the remote-tracking branches behind user's back means completely breaking the end-user expectation that --force-with-lease would do something useful even when it is not given the commit the user expects to see at the remote. Perhaps those third-party tools that want to run "git fetch" in the background can learn from how "prefetch" task works to avoid the breakage they are inflicting on their users?