git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Derrick Stolee <derrickstolee@github.com>
Cc: "Taylor Blau" <me@ttaylorr.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: tb/cruft-packs (was Re: What's cooking in git.git (Mar 2022, #01; Thu, 3))
Date: Mon, 7 Mar 2022 12:18:42 -0800	[thread overview]
Message-ID: <YiZoojeTodMr+Ypw@google.com> (raw)
In-Reply-To: <ebfac323-7567-6327-f5e6-0fd9e0356550@github.com>

Derrick Stolee wrote:
> On 3/7/2022 1:18 PM, Taylor Blau wrote:
>> On Mon, Mar 07, 2022 at 10:06:00AM -0800, Jonathan Nieder wrote:

>>>  2. Marking this as a repository format extension so it doesn't interact
>>>     poorly with Git implementations (including older versions of Git
>>>     itself) that are not aware of the new feature
>>
>> The design of cruft packs was done intentionally to avoid needing a
>> format extension. The cruft pack is "just a pack" to any older version
>> of Git. The only thing an older version of Git wouldn't understand is
>> how to interpret the .mtimes file. But that's no different than the
>> current behavior without cruft packs, where any unreachable object
>> inherits the mtime of its containing pack.
>>
>> So an older version of Git might prune a different set of objects than a
>> version that understands cruft packs depending on the contents of the
>> .mtimes file, the mtime of the cruft pack, and the width of the grace
>> period. But I think by downgrading you are more or less buying into the
>> existing behavior. So I don't think there is a compelling reason to
>> introduce a format extension here.
>
> In particular, older versions would first explode unreachable objects
> out of the cruft pack and into loose objects before expiring any of
> them based on the loose object mtime. There is no risk here of causing
> problems with older versions of Git and does not need an extension.

Surely when older and versions are acting on the same repository, they
would fight by exploding out unreachable objects, packing them back
into a cruft pack, etc, no?

Thanks,
Jonathan

  reply	other threads:[~2022-03-07 20:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04  4:31 What's cooking in git.git (Mar 2022, #01; Thu, 3) Junio C Hamano
2022-03-04 13:25 ` ab/plug-random-leaks (was Re: What's cooking in git.git (Mar 2022, #01; Thu, 3)) Derrick Stolee
2022-03-04 18:33   ` Ævar Arnfjörð Bjarmason
2022-03-17 12:46     ` [PATCH] tests: test show --word-diff --color-moved Michael J Gruber
2022-03-17 14:55       ` [PATCH v2 0/2] diff.c: fix a recent memory leak regression Ævar Arnfjörð Bjarmason
2022-03-17 14:55         ` [PATCH v2 1/2] tests: demonstrate "show --word-diff --color-moved" regression Ævar Arnfjörð Bjarmason
2022-03-17 15:54           ` Junio C Hamano
2022-03-17 14:55         ` [PATCH v2 2/2] diff.c: fix a double-free regression in a18d66cefb Ævar Arnfjörð Bjarmason
2022-03-04 15:35 ` tb/cruft-packs (was Re: What's cooking in git.git (Mar 2022, #01; Thu, 3)) Derrick Stolee
2022-03-07 18:06   ` Jonathan Nieder
2022-03-07 18:18     ` Taylor Blau
2022-03-07 18:32       ` Derrick Stolee
2022-03-07 20:18         ` Jonathan Nieder [this message]
2022-03-07 20:51           ` Derrick Stolee
2022-03-07 21:34             ` Junio C Hamano
2022-03-08  0:52               ` Taylor Blau
2022-03-08  0:25       ` Junio C Hamano
2022-03-08  0:49         ` Taylor Blau
2022-03-05 14:25 ` jc/stash-drop (was: " Ævar Arnfjörð Bjarmason
2022-03-07 18:22   ` jc/stash-drop Junio C Hamano
2022-03-07 13:49 ` ds/commit-graph-gen-v2-fixes (was Re: What's cooking in git.git (Mar 2022, #01; Thu, 3)) Derrick Stolee
2022-03-07 17:18   ` Junio C Hamano

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=YiZoojeTodMr+Ypw@google.com \
    --to=jrnieder@gmail.com \
    --cc=avarab@gmail.com \
    --cc=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.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.
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 NNTP newsgroup(s).