Re: Concurrent fetch commands
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Jan 4, 2024, 17:34 UTC
- Message-ID
- <ZZbsL8/2KfSITJv3@nand.local>
- In-Reply-To
- <xmqqwmsq83v3.fsf@gitster.g>
On Wed, Jan 03, 2024 at 02:10:56PM -0800, Junio C Hamano wrote:
Show 15 quoted lines
> 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.
Yeah, on thinking on it more I tend to agree here.
Show 8 quoted lines
> 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?
Probably so.
Thanks, Taylor