All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Barret Rhoden" <brho@google.com>,
	git@vger.kernel.org, "David Kastrup" <dak@gnu.org>,
	"Jeff Smith" <whydoubt@gmail.com>, "René Scharfe" <l.s.r@web.de>,
	"Stefan Beller" <stefanbeller@gmail.com>
Subject: Re: [PATCH v2 1/3] Move init_skiplist() outside of fsck
Date: Tue, 22 Jan 2019 13:28:49 -0500	[thread overview]
Message-ID: <20190122182849.GD4399@sigill.intra.peff.net> (raw)
In-Reply-To: <87ef953tyn.fsf@evledraar.gmail.com>

On Tue, Jan 22, 2019 at 10:46:56AM +0100, Ævar Arnfjörð Bjarmason wrote:

> > At which point, I think it might be simpler to just make git more
> > permissive with respect to those minor data errors (and in fact, we are
> > already pretty permissive for the most part in non-fsck operations).
> 
> Yeah it's probably better to make some of these "errors" softer
> warnings.
> 
> The X-Y issue I have is that I turned on transfer.fsckObjects, so then I
> can't clone repos with various minor historical issues in commit headers
> etc., so I maintain a big skip list. But what I was actually after was
> fsck checks like the .gitmodules security check.
>
> Of course I could chase them all down and turn them into
> warn/error/ignore individually, but it would be better if we e.g. had
> some way to say "serious things error, minor things warn", maybe with
> the option of only having the looser version on fetch but not recieve
> with the principle that we should be loose in what we accept from
> existing data but strict with new data #leftoverbits

Yeah, I think the current state here is rather unfortunate. The worst
part is that many of the things _are_ marked as warnings, but we reject
transfers even for warnings. So now we have "info" as well, which is
really just silly.

I think the big blocker to simply loosening "warning" is that the
current severities are pretty arbitrary. MISSING_NAME_BEFORE_EMAIL
probably ought to be warning, but it's an warning. Whereas HAS_DOTGIT is
a warning, but has pretty serious security implications.

So that does not save you from chasing them all down, but if you do, at
least the work could benefit everybody. ;)

-Peff

  parent reply	other threads:[~2019-01-22 18:28 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-07 21:30 [PATCH] blame: add the ability to ignore commits Barret Rhoden
2019-01-07 23:13 ` Junio C Hamano
2019-01-08 16:27   ` Barret Rhoden
2019-01-08 18:26     ` Junio C Hamano
2019-01-09 20:48       ` Barret Rhoden
2019-01-10 22:29         ` Junio C Hamano
2019-01-14 15:19           ` Barret Rhoden
2019-01-14 17:45             ` Junio C Hamano
2019-01-14 18:26               ` Randall S. Becker
2019-01-14 19:03                 ` Barret Rhoden
2019-01-15  6:08                 ` Junio C Hamano
2019-01-09 21:21       ` Stefan Beller
2019-01-08 13:12 ` Ævar Arnfjörð Bjarmason
2019-01-08 16:41   ` Barret Rhoden
2019-01-08 18:04     ` Barret Rhoden
2019-01-17 20:29 ` [PATCH v2 0/3] " Barret Rhoden
2019-01-17 20:29   ` [PATCH v2 1/3] Move init_skiplist() outside of fsck Barret Rhoden
2019-01-18  9:25     ` Johannes Schindelin
2019-01-18  9:45     ` Ævar Arnfjörð Bjarmason
2019-01-18 17:36       ` Junio C Hamano
2019-01-18 20:59         ` Johannes Schindelin
2019-01-18 21:30           ` Jeff King
2019-01-18 22:26             ` Ævar Arnfjörð Bjarmason
2019-01-22  7:12               ` Jeff King
2019-01-22  9:46                 ` Ævar Arnfjörð Bjarmason
2019-01-22 17:54                   ` Junio C Hamano
2019-01-22 18:28                   ` Jeff King [this message]
2019-01-17 20:29   ` [PATCH v2 2/3] blame: add the ability to ignore commits and their changes Barret Rhoden
2019-01-18  9:47     ` Johannes Schindelin
2019-01-18 17:33       ` Barret Rhoden
2019-01-20 18:19     ` René Scharfe
2019-01-22 15:26       ` Barret Rhoden
2019-01-22 18:14       ` Junio C Hamano
2019-01-22 19:35         ` Barret Rhoden
2019-01-23 19:26           ` Junio C Hamano
2019-02-01 20:37             ` Barret Rhoden
2019-01-17 20:29   ` [PATCH v2 3/3] blame: add a config option to mark ignored lines Barret Rhoden
2019-01-18 10:03     ` Johannes Schindelin
2019-01-18  9:52   ` [PATCH v2 0/3] blame: add the ability to ignore commits Ævar Arnfjörð Bjarmason

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=20190122182849.GD4399@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=brho@google.com \
    --cc=dak@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    --cc=stefanbeller@gmail.com \
    --cc=whydoubt@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.