All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Patrick Steinhardt <ps@pks.im>, git@vger.kernel.org
Subject: Re: [ANNOUNCE] Git v2.34.0-rc2
Date: Thu, 11 Nov 2021 12:33:03 -0800	[thread overview]
Message-ID: <xmqqy25ujuv4.fsf@gitster.g> (raw)
In-Reply-To: <YY17rBFIdDl+H47I@coredump.intra.peff.net> (Jeff King's message of "Thu, 11 Nov 2021 15:23:08 -0500")

Jeff King <peff@peff.net> writes:

> On Thu, Nov 11, 2021 at 09:32:29AM -0800, Junio C Hamano wrote:
>
>> ...  So in this particular example, it would not matter if the
>> new unsorted traversal is subtly broken (I think the extent of the
>> damage is similar to making the SLOP problem deliberately worse),
>> but I am not sure if there are other failure modes that would yield
>> outright incorrect result.
>
> Yes, I think that framing is right: it is making SLOP much worse. We
> could similarly have had bogus timestamps in those commits which would
> cause the same outcome. So in that sense it is nothing new. On the other
> hand, I wonder how often it will cause extra traversal work (keeping in
> mind that this commit traversal is just the first stage; after we find
> the commits, then we talk all of their trees, which is the more
> expensive part).
>
> For the case of adding new commits directly on top of another branch, I
> think there would be no change. But any time you have to walk down to a
> common fork point (e.g., imagine I made a new branch forked from an old
> bit of history), we may fail to find that. I haven't quite constructed
> an example, but I have a feeling we could end up walking over
> arbitrarily long segments of history.
> ...
> I'd be curious to hear Patrick's thoughts on the whole thing.

Yes.  I'm tempted to wait for him to chime in.

  reply	other threads:[~2021-11-11 20:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-10  0:59 [ANNOUNCE] Git v2.34.0-rc2 Junio C Hamano
2021-11-10  5:41 ` Jeff King
2021-11-10  6:00   ` Jeff King
2021-11-10  8:11     ` Carlo Arenas
2021-11-10  8:22       ` Jeff King
2021-11-10  9:15         ` Carlo Arenas
2021-11-10  9:35           ` Jeff King
2021-11-10  9:39     ` [PATCH] RelNotes: mention known crasher when ssh signing with OpenSSH 8.7 Carlo Marcelo Arenas Belón
2021-11-10 21:39       ` Junio C Hamano
2021-11-10 22:11         ` Junio C Hamano
2021-11-11  9:16           ` Jeff King
     [not found]             ` <YY7/peK1EOHtATEI@camp.crustytoothpaste.net>
2021-11-13  0:16               ` Junio C Hamano
2021-11-10 21:49     ` [ANNOUNCE] Git v2.34.0-rc2 Junio C Hamano
2021-11-10  6:35 ` Johannes Altmanninger
2021-11-10  8:22   ` Jeff King
2021-11-10 21:43     ` Junio C Hamano
2021-11-11 12:07 ` Jeff King
2021-11-11 17:32   ` Junio C Hamano
2021-11-11 20:23     ` Jeff King
2021-11-11 20:33       ` Junio C Hamano [this message]
2021-11-15 15:06       ` Patrick Steinhardt
2021-11-15 15:27         ` Jeff King
2021-11-15 16:52       ` Jeff King

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=xmqqy25ujuv4.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --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.