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 02:53:47 -0400	[thread overview]
Message-ID: <20150908065347.GG26331@sigill.intra.peff.net> (raw)
In-Reply-To: <CACBZZX6ZYDEPrQorg=pVh734ua+x55SYoKKvSZ_h0GQaR=m+8w@mail.gmail.com>

On Mon, Sep 07, 2015 at 02:11:15PM +0200, Ævar Arnfjörð Bjarmason wrote:

> This turned out to be a pretty trivial filesystem error.
> refs/heads/master wasn't readable by the backup process, but some
> other stuff in refs/heads and objects/* was.
>
> [...]
>
> I wanted to check if this was a regression and got as far back as
> v1.4.3 with the same behavior before the commands wouldn't work
> anymore due to changes in the git config parsing code.

Right, it has basically always been this way. for_each_ref() silently
eats oddities or errors while reading refs. Calling for_each_rawref()
will include them, but we don't do it in most places; it would make
non-critical operations on a corrupted repo barf.  And it is difficult
to know what is "critical" inside the code. You might be calling
"upload-pack" to salvage what you can from a corrupted repo, or to make
a backup where you want to know what is corrupted and what is not.

Commit 49672f2 introduced a "ref paranoia" environment variable to let
you specify this (and robust backups was definitely one of the use cases
I had in mind). It's a little tricky to use with upload-pack because you
may be crossing an ssh boundary, but:

  git clone -u 'GIT_REF_PARANOIA=1 git-upload-pack' ...

should work.

With your case:

  $ git clone --no-local -u 'GIT_REF_PARANOIA=1 git-upload-pack' repo repo-checkout
  Cloning into 'repo-checkout'...
  fatal: git upload-pack: not our ref 0000000000000000000000000000000000000000
  fatal: The remote end hung up unexpectedly

Without "--no-local" it behaves weirdly, but I would not recommend local
clones in general if you are trying to be careful. They optimize out a
lot of the safety checks, and we do things like copy the packed-refs
file wholesale.

And certainly the error message is not the greatest. upload-pack is not
checking for the REF_ISBROKEN flag, so it just dumps:

  0000000000000000000000000000000000000000 refs/heads/master

in the advertisement, and the client happily requests that object.
REF_PARANOIA is really just a band-aid to feed the broken refs to the
normal code paths, which typically barf on their own. :)

Something like this:

diff --git a/upload-pack.c b/upload-pack.c
index 89e832b..3c621a5 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -731,6 +731,9 @@ static int send_ref(const char *refname, const struct object_id *oid,
 	if (mark_our_ref(refname, oid))
 		return 0;
 
+	if (flag & REF_ISBROKEN)
+		warning("remote ref '%s' is broken", refname);
+
 	if (capabilities) {
 		struct strbuf symref_info = STRBUF_INIT;
 
kind of helps, but the advertisement is too early for us to send
sideband messages. So it makes it to the user if the transport is local
or ssh, but not over git:// or http.

That's something we could do better with protocol v2 (we'll negotiate
capabilities before the advertisement).

-Peff

  reply	other threads:[~2015-09-08  6:54 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 [this message]
2015-09-08 12:16   ` Ævar Arnfjörð Bjarmason
2015-09-08 22:06     ` 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=20150908065347.GG26331@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).