Taylor Blau <me@xxxxxxxxxxxx> 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?
