git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Michael Haggerty <mhagger@alum.mit.edu>
Subject: Re: [PATCH 0/5] not making corruption worse
Date: Wed, 18 Mar 2015 06:21:08 -0400	[thread overview]
Message-ID: <20150318102108.GA27249@peff.net> (raw)
In-Reply-To: <xmqqh9tjme0l.fsf@gitster.dls.corp.google.com>

On Tue, Mar 17, 2015 at 03:54:02PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > But it strikes me as weird that we consider the _tips_ of history to be
> > special for ignoring breakage. If the tip of "bar" is broken, we omit
> > it. But if the tip is fine, and there's breakage three commits down in
> > the history, then doing a clone is going to fail horribly, as
> > pack-objects realizes it can't generate the pack. So in practice, I'm
> > not sure how much you're buying with the "don't mention broken refs"
> > code.
> 
> I think this is a trade-off between strictness and convenience.  Is
> it preferrable that every time you try to clone a repository you get
> reminded that one of its refs point at a bogus object and you
> instead have to do "git fetch $there" with a refspec that excludes
> the broken one, or is it OK to allow clones and fetches silently
> succeed as if nothing is broken?

I think the real issue is that we do not know on the server side what
the client wants. Is it "tell me the refs, so I can grab just the one I
need, and I don't care about the broken ones"? Or is it "I want
everything you have, and tell me if you can't serve it"?  You want
strictness in the latter case, but not in the former. But if we were to
err on the side of strictness, you could not do the former at all
(because upload-pack would barf before the client even has a chance to
say anything).

I'm not sure if anyone will actually find GIT_REF_PARANOIA useful for
something like that or not. As an environment variable, it may impact a
filesystem-local clone, but it would not travel across a TCP connection.
And doing so is tough, because the ref advertisement happens before the
client speaks.

If we ever have a client-speaks-first protocol, one extension could
allow the client to flip the paranoia switch on the server. But my main
goal here was really just making "prune" safer, so I'm happy enough with
what this series does, for now.

> In some parts of the system there is a movement to make this trade
> off tweakable (hint: what happened to the knobs to fsck that allow
> certain kinds of broken objects in the object store?  did the topic
> go anywhere?). This one so far lacked such a knob to tweak, and I
> view your paranoia bit as such a knob.

I think I promised several times to review that topic and never got
around to it. Which makes me a bad person. It is still on my todo list.

-Peff

  reply	other threads:[~2015-03-18 10:21 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-17  7:27 [PATCH 0/5] not making corruption worse Jeff King
2015-03-17  7:28 ` [PATCH 1/5] t5312: test object deletion code paths in a corrupted repository Jeff King
2015-03-17 18:34   ` Johannes Sixt
2015-03-17 18:55     ` Jeff King
2015-03-18 20:42       ` Johannes Sixt
2015-03-19 20:04   ` Junio C Hamano
2015-03-19 20:51     ` Jeff King
2015-03-19 21:23       ` Junio C Hamano
2015-03-19 21:47         ` Jeff King
2015-03-19 21:49           ` Junio C Hamano
2015-03-19 21:52             ` Jeff King
2015-03-20  1:16   ` Eric Sunshine
2015-03-20  1:32     ` Jeff King
2015-03-20  1:37       ` Eric Sunshine
2015-03-20  2:08         ` test &&-chain lint (was: [PATCH 1/5] t5312: test object deletion code paths in a corrupted repository) Jeff King
2015-03-20  2:25           ` Jeff King
2015-03-20  5:10             ` Jeff King
2015-03-20  7:18               ` Eric Sunshine
2015-03-20  6:51             ` test &&-chain lint Junio C Hamano
2015-03-20 17:04               ` Junio C Hamano
2015-03-20 17:24                 ` Jeff King
2015-03-20 17:34                   ` Junio C Hamano
2015-03-20 17:59                     ` Jeff King
2015-03-17  7:29 ` [PATCH 2/5] refs: introduce a "ref paranoia" flag Jeff King
2015-03-19 20:13   ` Junio C Hamano
2015-03-19 21:00     ` Jeff King
2015-03-19 21:31       ` Junio C Hamano
2015-03-19 21:51         ` Jeff King
2015-03-17  7:30 ` [PATCH 3/5] prune: turn on ref_paranoia flag Jeff King
2015-03-17  7:31 ` [PATCH 4/5] repack: turn on "ref paranoia" when doing a destructive repack Jeff King
2015-03-17  7:31 ` [PATCH 5/5] refs.c: drop curate_packed_refs Jeff King
2015-03-20  1:27   ` Eric Sunshine
2015-03-17  7:37 ` [PATCH 0/5] not making corruption worse Jeff King
2015-03-17 22:54   ` Junio C Hamano
2015-03-18 10:21     ` Jeff King [this message]
2015-03-20 18:42 ` [PATCH v2 " Jeff King
2015-03-20 18:43   ` [PATCH v2 1/5] t5312: test object deletion code paths in a corrupted repository Jeff King
2015-03-20 18:43   ` [PATCH v2 2/5] refs: introduce a "ref paranoia" flag Jeff King
2015-03-20 18:43   ` [PATCH v2 3/5] prune: turn on ref_paranoia flag Jeff King
2015-03-20 18:43   ` [PATCH v2 4/5] repack: turn on "ref paranoia" when doing a destructive repack Jeff King
2015-03-20 18:43   ` [PATCH v2 5/5] refs.c: drop curate_packed_refs 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150318102108.GA27249@peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mhagger@alum.mit.edu \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).