On 03.01.24 23:10, Junio C Hamano wrote: > 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. That's good, but it's for a very different purpose than an IDE's background fetch. git maintenance's prefetch is just to improve performance for the next pull; the point of an IDE's background fetch is to show me which of my remote branches have new stuff that I might be interested in pulling, without having to fetch myself. So I *want* this to be mucking with my 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. That's an interesting point that indeed hasn't been brought up yet. However, don't we all agree that --force-with-lease without specifying a commit is not a good idea anyway, in general? That's why --force-if-includes was invented, isn't it? > 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? Again, what you call "breakage" here is the very point of a background fetch for me, so I don't want it to be avoided. (For FETCH_HEAD, yes, and I learned that we have --no-write-fetch-head for that, but for remote-tracking branches, no.)
