From: Taylor Blau <me@ttaylorr.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Derrick Stolee <derrickstolee@github.com>
Subject: Re: [PATCH v3] builtin/pack-objects.c: introduce `pack.extraCruftTips`
Date: Wed, 3 May 2023 19:50:30 -0400 [thread overview]
Message-ID: <ZFLzC1slvOAD6udn@nand.local> (raw)
In-Reply-To: <xmqqjzxpm172.fsf@gitster.g>
On Wed, May 03, 2023 at 04:42:41PM -0700, Junio C Hamano wrote:
> Storing them inside cruft packs may be a reasonable choice to make
> today, in the sense that among various object storage mechansim, the
> cruft pack mechanism may be the best fit in today's system, but it
> does not have to stay that way. Naming the variable to specify the
> hooks with name "cruft" in them would make it hard to explain once
> we find an even better storage mechanism to store such a "not really
> used but want to keep" objects.
I dunno. I thought about this too, and I get your argument, but I am not
convinced that a future mechanism would lend itself well to keeping
around additional sets of objects in the same way cruft packs do. In
that case, we would prefer having called this `pack.extraCruftTips` and
relegating it to the cruft pack system.
We could make this more generic, and extend support to the legacy
prune-via-loose mechanism. But like I said to Peff, I have a hard time
imagining anybody using it.
So, I'm torn. I see what you're saying, but I think I still tend to fall
on the side of leaving it as-is.
Thanks,
Taylor
next prev parent reply other threads:[~2023-05-03 23:50 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-20 17:27 [PATCH] builtin/pack-objects.c: introduce `pack.extraCruftTips` Taylor Blau
2023-04-20 18:12 ` Junio C Hamano
2023-04-20 19:30 ` Taylor Blau
2023-04-20 19:52 ` Junio C Hamano
2023-04-20 20:48 ` Taylor Blau
2023-04-21 0:10 ` Chris Torek
2023-04-21 2:14 ` Taylor Blau
2023-04-25 19:42 ` Derrick Stolee
2023-04-25 21:25 ` Taylor Blau
2023-04-26 10:52 ` Derrick Stolee
2023-05-03 0:06 ` Taylor Blau
2023-05-03 0:09 ` [PATCH v2] " Taylor Blau
2023-05-03 14:01 ` Derrick Stolee
2023-05-03 19:59 ` Jeff King
2023-05-03 21:22 ` Taylor Blau
2023-05-05 21:23 ` Jeff King
2023-05-06 0:06 ` Taylor Blau
2023-05-06 0:14 ` Taylor Blau
2023-05-03 21:28 ` Taylor Blau
2023-05-05 21:26 ` Jeff King
2023-05-05 22:13 ` Jeff King
2023-05-06 0:13 ` Taylor Blau
2023-05-06 0:20 ` Taylor Blau
2023-05-06 2:12 ` Jeff King
2023-05-03 22:05 ` [PATCH v3] " Taylor Blau
2023-05-03 23:18 ` Junio C Hamano
2023-05-03 23:42 ` Junio C Hamano
2023-05-03 23:48 ` Taylor Blau
2023-05-03 23:50 ` Taylor Blau [this message]
2023-05-05 21:39 ` Jeff King
2023-05-05 22:19 ` 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=ZFLzC1slvOAD6udn@nand.local \
--to=me@ttaylorr.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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.