git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [BUG] "fatal: bad object .alternate" during fetch with alternates
Date: Fri, 8 Nov 2019 03:54:13 -0500	[thread overview]
Message-ID: <20191108085413.GA4356@sigill.intra.peff.net> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1911071349590.46@tvgsbejvaqbjf.bet>

On Thu, Nov 07, 2019 at 01:58:04PM +0100, Johannes Schindelin wrote:

> So what about the idea of ignoring (with a warning) them instead,
> without bothering to try saying much about the alternate itself? I.e.
> something like this patch (which is admittedly a bit verbose because it
> _also_ has to update a signature):
>
> [...]
> @@ -1569,7 +1569,11 @@ static void add_one_alternate_ref(const struct object_id *oid,
>  	struct add_alternate_refs_data *data = vdata;
>  	struct object *obj;
> 
> -	obj = get_reference(data->revs, name, oid, data->flags);
> +	if (!(obj = get_reference(data->revs, name, oid, data->flags, 1))) {
> +		warning("ignoring stale alternate reference to '%s'",
> +			oid_to_hex(oid));
> +		return;
> +	}
>  	add_rev_cmdline(data->revs, obj, name, REV_CMD_REV, data->flags);
>  	add_pending_object(data->revs, obj, name);
>  }

I don't think it makes sense to tie this to "--alternate-refs" in this
way. I think there are two ways to look at resolving this:

  - for the UNINTERESTING side of a traversal, we might be willing to
    ignore a missing object. But then it would apply equally to
    non-alternates, too. (And we do this already, but not for ref tips,
    since those aren't just "stale" but rather indicative of a
    corruption).

  - any alternate-ref borrowing is an optimization and thus best-effort.
    So we should treat them specially, whether UNINTERESTING or not. But
    then I think the right place to do that is not inside rev-list, but
    in for_each_alternate_ref(), or even in the for-each-ref run inside
    the alternate repository. Then it would help rev-list, but also
    avoid advertising the bogus object across a push/fetch.

-Peff

      reply	other threads:[~2019-11-08  8:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06 19:48 [BUG] "fatal: bad object .alternate" during fetch with alternates Johannes Schindelin
2019-11-06 20:59 ` Jeff King
2019-11-06 21:25   ` Jeff King
2019-11-06 21:42   ` Jeff King
2019-11-07 12:58     ` Johannes Schindelin
2019-11-08  8:54       ` 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

  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=20191108085413.GA4356@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.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.
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).