git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Git <git@vger.kernel.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Duy Nguyễn" <pclouds@gmail.com>
Subject: Re: Bug: git-upload-pack will return successfully even when it can't read all references
Date: Tue, 8 Sep 2015 18:06:11 -0400	[thread overview]
Message-ID: <20150908220611.GE24159@sigill.intra.peff.net> (raw)
In-Reply-To: <CACBZZX6Ag5pjx_AhS_aN=rvJBcy+Nh+PXfdeEqxFdgxvL3NMbw@mail.gmail.com>

On Tue, Sep 08, 2015 at 02:16:03PM +0200, Ævar Arnfjörð Bjarmason wrote:

> I wonder if --upload-pack="GIT_REF_PARANOIA=1 git-upload-pack" should
> be the default when running fetch if you have --prune enabled. There's
> a particularly bad edge case now where if you have permission errors
> on the master repository and run --prune on your backup along with a
> --mirror clone to mirror the refs, then when you have permission
> issues you'll prune everything from the backup.
> 
> But yeah, a proper fix needs protocol v2. Because among other things
> that --upload-pack hack will only work for ssh, not http.

Right. There is no real way to flip the flag from the client side,
because we cannot reliably communicate it. Once we have such a
mechanism, it might actually make sense to _always_ flip on paranoia.
That is, we would rather an operation fail and be retried with in a
"loose" mode explicitly. That's safer. It's less convenient when you
have a broken repo, but surely that's the exception, right?

-Peff

      reply	other threads:[~2015-09-08 22:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-07 12:11 Bug: git-upload-pack will return successfully even when it can't read all references Ævar Arnfjörð Bjarmason
2015-09-08  6:53 ` Jeff King
2015-09-08 12:16   ` Ævar Arnfjörð Bjarmason
2015-09-08 22:06     ` Jeff King [this message]

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=20150908220611.GE24159@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    --cc=spearce@spearce.org \
    --cc=torvalds@linux-foundation.org \
    /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 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 NNTP newsgroup(s).