From: Jeff King <peff@peff.net>
To: Derrick Stolee <stolee@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, jonathantanmy@google.com, me@ttaylorr.com,
Derrick Stolee <dstolee@microsoft.com>,
git@jeffhostetler.com
Subject: Re: [PATCH] connected.c: reprepare packs for corner cases
Date: Thu, 12 Mar 2020 22:34:27 -0400 [thread overview]
Message-ID: <20200313023427.GB900007@coredump.intra.peff.net> (raw)
In-Reply-To: <20200313023034.GA900007@coredump.intra.peff.net>
On Thu, Mar 12, 2020 at 10:30:34PM -0400, Jeff King wrote:
> So that would actually argue that your patch is putting it in the right
> place. It's _not_ fetch's responsibility to reprepare_packed_git(). It's
> the loop in check_connected() that is skipping the usual reprepare
> logic, and shouldn't.
>
> And one fix (which you did) is to just preemptively reprepare right
> above that loop. Some other solutions are:
I know I've now suggested that your patch is both wrong and right. :)
Just to be clear, at this point I think I'd be OK with either solution.
If it's going into check_connected(), the commit message should argue
that the loop there is at fault for not doing the usual fallback, and a
single explicit reprepare() is cheap enough to cover the case we care
about (and that we don't have to worry about racing with somebody else
repacking because the point of that flag is that we're in a brand new
repo).
Repreparing earlier in the transport-helper code _could_ still protect
against other similar loops, which is an argument for putting it there.
But I'd be inclined to say those other loops should be corrected.
-Peff
next prev parent reply other threads:[~2020-03-13 2:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-12 15:36 [PATCH] connected.c: reprepare packs for corner cases Derrick Stolee via GitGitGadget
2020-03-12 16:39 ` Jonathan Tan
2020-03-12 17:34 ` Derrick Stolee
2020-03-12 20:42 ` Junio C Hamano
2020-03-12 21:16 ` Jeff King
2020-03-12 21:26 ` Jeff King
2020-03-13 0:54 ` Derrick Stolee
2020-03-13 1:14 ` Junio C Hamano
2020-03-13 2:30 ` Jeff King
2020-03-13 2:34 ` Jeff King [this message]
2020-03-13 12:43 ` Derrick Stolee
2020-03-13 21:11 ` [PATCH v2] " Derrick Stolee via GitGitGadget
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200313023427.GB900007@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=dstolee@microsoft.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=jonathantanmy@google.com \
--cc=me@ttaylorr.com \
--cc=stolee@gmail.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).