All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Patrick Steinhardt <ps@pks.im>,
	Oswald Buddenhagen <oswald.buddenhagen@gmx.de>,
	Stefan Haller <lists@haller-berlin.de>,
	git@vger.kernel.org
Subject: Re: Concurrent fetch commands
Date: Thu, 4 Jan 2024 12:34:39 -0500	[thread overview]
Message-ID: <ZZbsL8/2KfSITJv3@nand.local> (raw)
In-Reply-To: <xmqqwmsq83v3.fsf@gitster.g>

On Wed, Jan 03, 2024 at 02:10:56PM -0800, Junio C Hamano wrote:
> 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.

> 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

      parent reply	other threads:[~2024-01-04 17:34 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
2024-01-04 22:25                     ` Mike Hommey
2024-01-04 17:34               ` Taylor Blau [this message]

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=ZZbsL8/2KfSITJv3@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=lists@haller-berlin.de \
    --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.