From: Junio C Hamano <gitster@pobox.com>
To: Mike Hommey <mh@glandium.org>
Cc: Stefan Haller <lists@haller-berlin.de>,
Taylor Blau <me@ttaylorr.com>, Patrick Steinhardt <ps@pks.im>,
Oswald Buddenhagen <oswald.buddenhagen@gmx.de>,
git@vger.kernel.org
Subject: Re: Concurrent fetch commands
Date: Thu, 04 Jan 2024 14:14:50 -0800 [thread overview]
Message-ID: <xmqq34vc7nl1.fsf@gitster.g> (raw)
In-Reply-To: <20240104205408.h5wvcissfbat7acw@glandium.org> (Mike Hommey's message of "Fri, 5 Jan 2024 05:54:08 +0900")
Mike Hommey <mh@glandium.org> writes:
> On Thu, Jan 04, 2024 at 01:01:26PM +0100, Stefan Haller wrote:
>> 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.
>
> Use `git remote update`?
Hmph, it seems that it does not pass "--no-write-fetch-head" so it
would interfere with the foreground "fetch" or "pull" the end user
consciously makes, exactly the same way Stefan's demonstration in
the first message in the thread, no?
next prev parent reply other threads:[~2024-01-04 22:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-31 13:30 Concurrent fetch commands Stefan Haller
2023-12-31 13:48 ` Dragan Simic
2023-12-31 13:50 ` Konstantin Tokarev
2023-12-31 14:01 ` Dragan Simic
2024-01-01 11:23 ` Stefan Haller
2024-01-01 15:47 ` Federico Kircheis
2023-12-31 17:27 ` Junio C Hamano
2023-12-31 17:41 ` Dragan Simic
2024-01-01 11:30 ` Stefan Haller
2024-01-01 11:42 ` Stefan Haller
2024-01-03 7:33 ` Patrick Steinhardt
2024-01-03 8:11 ` Patrick Steinhardt
[not found] ` <ZZU1TCyQdLqoLxPw@ugly>
2024-01-03 10:40 ` Patrick Steinhardt
2024-01-03 16:40 ` Taylor Blau
2024-01-03 22:10 ` Junio C Hamano
2024-01-04 12:01 ` Stefan Haller
2024-01-04 20:54 ` Mike Hommey
2024-01-04 22:14 ` Junio C Hamano [this message]
2024-01-04 22:25 ` Mike Hommey
2024-01-04 17:34 ` Taylor Blau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq34vc7nl1.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=lists@haller-berlin.de \
--cc=me@ttaylorr.com \
--cc=mh@glandium.org \
--cc=oswald.buddenhagen@gmx.de \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.