Re: Concurrent fetch commands
- From
- Stefan Haller <lists@haller-berlin.de>
- Date
- Jan 4, 2024, 12:01 UTC
- Message-ID
- <80efcb43-122c-421a-b763-6da6ff620538@haller-berlin.de>
- In-Reply-To
- <xmqqwmsq83v3.fsf@gitster.g>
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.
Show 5 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.
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.)