From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] fetch: when deepening, check connectivity fully
Date: Wed, 27 Jun 2018 15:56:30 -0700 [thread overview]
Message-ID: <xmqqwoujdejl.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20180627224033.150025-1-jonathantanmy@google.com> (Jonathan Tan's message of "Wed, 27 Jun 2018 15:40:33 -0700")
Jonathan Tan <jonathantanmy@google.com> writes:
>> Hmph, remind me how old and/or new shallow cut-off points affect
>> this traversal? In order to verify that everything above the new
>> cut-off points, opt->shallow_file should be pointing at the new
>> cut-off points, then we do the full sweep (without --not --all) to
>> ensure we won't find missing or broken objects but still stop at the
>> new cut-off points, and then only after check_connected() passes,
>> update the shallow file to make new shallow cut-off points active
>> (and if the traversal fails, then we do nto install the new shallow
>> cut-off points)?
>
> That is the way it should work, but after thinking about it once more, I
> realize that it isn't.
>
> opt->shallow_file is not set to anything. And fetch-pack updates the
> shallow file by itself (at least, that is my understanding of
> update_shallow() in fetch-pack.c) before fetch calls check_connected(),
> meaning that if check_connected() fails, there is still no rollback of
> the shallow file.
Ouch. We need to fix that; otherwise, a broken server will keep
giving you a corrupt repository even with this fix, no?
next prev parent reply other threads:[~2018-06-27 22:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-27 17:32 [PATCH] fetch: when deepening, check connectivity fully Jonathan Tan
2018-06-27 19:57 ` Junio C Hamano
2018-06-27 22:40 ` Jonathan Tan
2018-06-27 22:56 ` Junio C Hamano [this message]
2018-06-29 22:30 ` Jonathan Tan
2018-06-27 20:17 ` Junio C Hamano
2018-06-27 22:51 ` Jonathan Tan
2018-06-27 22:58 ` Junio C Hamano
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=xmqqwoujdejl.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jonathantanmy@google.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 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).