From: Jeff King <peff@peff.net>
To: Taylor Blau <me@ttaylorr.com>
Cc: "SZEDER Gábor" <szeder.dev@gmail.com>,
git@vger.kernel.org, dstolee@microsoft.com, gitster@pobox.com,
martin.agren@gmail.com
Subject: Re: [PATCH 7/7] commit-graph.c: introduce '--[no-]check-oids'
Date: Sun, 3 May 2020 05:40:05 -0400 [thread overview]
Message-ID: <20200503094005.GD170902@coredump.intra.peff.net> (raw)
In-Reply-To: <20200501223848.GH41612@syl.local>
On Fri, May 01, 2020 at 04:38:48PM -0600, Taylor Blau wrote:
> But, are there ever any callers that *wouldn't* want this behavior? As
> far as I can tell, probably not. We're only going to be permitting
> *more* inputs to 'git commit-graph write', and I seriously doubt that
> anybody is depending on the above behavior. (Of course, if that's not
> the case, I'd love for somebody to speak up here and we can continue
> the course on this patch).
>
> So, I propose the following:
>
> * We drop the idea of '--[no-]{check,verify}-oids', and always
> silently ignore non-commit inputs, retaining the existing behavior
> of always complaining about things that aren't valid hex OIDs, such
> as "HEAD".
>
> * We always error out on missing or corrupt commit OIDs, including
> valid OIDs that don't resolve to any object, or resolve to a tag
> that can't be fully peeled.
>
> Does that seem reasonable?
FWIW, I think that is the best direction. If anybody is depending on the
"commit-graph write will complain about non-commits" behavior, they
could only be doing so for a few versions; prior to v2.24.0 we did not.
-Peff
next prev parent reply other threads:[~2020-05-03 9:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-14 4:03 [PATCH 0/7] commit-graph: split strategies, '--[no-]check-oids' Taylor Blau
2020-04-14 4:04 ` [PATCH 1/7] t/helper/test-read-graph.c: support commit-graph chains Taylor Blau
2020-04-14 4:04 ` [PATCH 2/7] builtin/commit-graph.c: support for '--split[=<strategy>]' Taylor Blau
2020-04-14 4:04 ` [PATCH 3/7] builtin/commit-graph.c: introduce split strategy 'no-merge' Taylor Blau
2020-04-14 4:04 ` [PATCH 4/7] builtin/commit-graph.c: introduce split strategy 'replace' Taylor Blau
2020-04-14 4:04 ` [PATCH 5/7] oidset: introduce 'oidset_size' Taylor Blau
2020-04-14 4:04 ` [PATCH 6/7] commit-graph.h: replace 'commit_hex' with 'commits' Taylor Blau
2020-04-14 4:04 ` [PATCH 7/7] commit-graph.c: introduce '--[no-]check-oids' Taylor Blau
2020-04-15 4:29 ` Taylor Blau
2020-04-15 4:31 ` Taylor Blau
2020-04-22 10:55 ` SZEDER Gábor
2020-04-22 23:39 ` Taylor Blau
2020-04-24 10:59 ` SZEDER Gábor
2020-05-01 22:38 ` Taylor Blau
2020-05-03 9:40 ` Jeff King [this message]
2020-05-03 16:55 ` Junio C Hamano
2020-05-04 14:59 ` Jeff King
2020-05-04 16:29 ` Junio C Hamano
2020-05-04 22:16 ` Taylor Blau
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=20200503094005.GD170902@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=martin.agren@gmail.com \
--cc=me@ttaylorr.com \
--cc=szeder.dev@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.
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.