All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Chris Torek <chris.torek@gmail.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	Derrick Stolee <derrickstolee@github.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] builtin/pack-objects.c: introduce `pack.extraCruftTips`
Date: Thu, 20 Apr 2023 22:14:10 -0400	[thread overview]
Message-ID: <ZEHxctCveqt06g4a@nand.local> (raw)
In-Reply-To: <CAPx1GvdmzDVbiZGeguVVjWe+eAhj6=yG18Rd6wLhZVrnd4jiBg@mail.gmail.com>

On Thu, Apr 20, 2023 at 05:10:31PM -0700, Chris Torek wrote:
> On Thu, Apr 20, 2023 at 10:35 AM Taylor Blau <me@ttaylorr.com> wrote:
> > +Output must contain exactly one hex object ID per line, and nothing
> > +else. Objects which cannot be found in the repository are ignored.
>
> The first part sounds good, as a rigid output format can always be
> relaxed later if necessary. The second I'm less sure about: should
> there perhaps be a --{no-,}missing-objects option to control it?

Maybe, although specifying it might be a little tricky.

I think you'd have to tie that setting into the configuration instead of
passing it through as a command-line argument. So things get interesting
when you have multiple `pack.extraCruftTips` commands: which of them are
allowed (or not allowed) to specify missing objects?

I think you could do something like:

    [packExtraCruft "foo"]
        exec = /path/to/script
        allowMissing = true

and specify multiple pack.extraCruftTips-esque programs, that each allow
(or not) passing missing objects.

I dunno. It might be overkill, but I could also see a compelling
argument towards doing something like that. It may equally be OK to set
`pack.allowMissingExtraCruftTips` once and have it apply to all values
of `pack.extraCruftTips`.

That might be a reasonable compromise, and it doesn't feel like overkill
to me. I can't easily imagine a circumstance where you'd want to allow
some programs to specify missing objects and not others.

Thanks,
Taylor

  reply	other threads:[~2023-04-21  2:14 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 [this message]
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
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=ZEHxctCveqt06g4a@nand.local \
    --to=me@ttaylorr.com \
    --cc=chris.torek@gmail.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.