From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-6.2 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, LIST_MIRROR_RECEIVED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id AFFC01F670 for ; Mon, 21 Feb 2022 17:51:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377865AbiBUOdn (ORCPT ); Mon, 21 Feb 2022 09:33:43 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:43880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377983AbiBUOcr (ORCPT ); Mon, 21 Feb 2022 09:32:47 -0500 Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A688220F5 for ; Mon, 21 Feb 2022 06:32:24 -0800 (PST) Received: by mail-vk1-xa2e.google.com with SMTP id w128so8024469vkd.3 for ; Mon, 21 Feb 2022 06:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=a2meDT4IZWyshGW7S4puXprQQ6oR6BnZfRsLgrIP5uI=; b=sL4rac8/1YjNV8fDlOeUOWG8mBQUMg1BRxaz40rHCHKAjIyJqBAuuW0drQb+mzSmeV Y3Qkr3/K2qpx6XQZ4Jr+CDjrnrkI/0JwGdWHRQoE8MIjvCGrwkiP/P5jA0VpzYx69kyI FhoQfZeEa/JBuNKSU+YRxjsWSFuzJQ6iPvLNjnWUox5UJr2kXJA4wHHoPZ0vaQeGGn2w HGDeUUir7CDyZJdh6xtx7GqbK3yt0ikCaCR+84oMvNq1JpuNUdwEjgwsqFJ0Na7PL3X0 6YjZTpNAd1705j4asqxIV5EJWBYtauz7W8UMIa+HNrgD6bvRZ/BW6d3XEQbaGIjk782a GiqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=a2meDT4IZWyshGW7S4puXprQQ6oR6BnZfRsLgrIP5uI=; b=6PEOtZl5x2zFftwa6B8PN4lYOEipOg5CBA1ISYn7jzwlHVurcnbCW1xlPgB9iZHqzV rpjDFMh9tth6cEpF2rs7MG8lND4e2ONbEwT0A0XxnFQv0doN8kJN8G2HioX69gP4SVXw 0ZcMw2x7yNvH1doH8ueZMPwaKaTpBzTkte0VgAuHGfUqkoBy6MbZx30ziF3hw4aQCwod v+Km40zEE2kfEYv6jKvek7ViiSxfpRhNKrKLzd2YQTxBzDaLyUPXUgoq+dPVhnTSUgB3 9e9wcNadhSHfp8mTvn6BWsrysjuRD/P7ESlrmi4v8moZlZQfTsOeRfp98op9UlEoS4Ry 9LAw== X-Gm-Message-State: AOAM531diUtrsRW2gvDP9RCyUDMyR4xVb4mr5kaeoY6iYpm+2f14Ph9D EyNqFXjKe2ecmlJmFXdaYGnjJ4sg6xCEHZ4g+z65pZdNZho= X-Google-Smtp-Source: ABdhPJwLS+u7SePxb3H+KbDoF9oIQ2aHg7S+Xb1QFFTME/sPC4m/Lw+bUKAe24YCPUTnhmkiaNMqKmWR/MC9CGzIx2M= X-Received: by 2002:a05:6122:16a4:b0:331:1be5:3d2c with SMTP id 36-20020a05612216a400b003311be53d2cmr7893301vkl.33.1645453943108; Mon, 21 Feb 2022 06:32:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Han-Wen Nienhuys Date: Mon, 21 Feb 2022 15:32:11 +0100 Message-ID: Subject: Re: [PATCH v2 4/7] reftable: avoid writing empty keys at the block layer To: Junio C Hamano Cc: Han-Wen Nienhuys via GitGitGadget , git@vger.kernel.org, Han-Wen Nienhuys Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Fri, Feb 18, 2022 at 12:55 AM Junio C Hamano wrote: > > @@ -358,6 +363,8 @@ int block_reader_first_key(struct block_reader *br,= struct strbuf *key) > > int n =3D reftable_decode_key(key, &extra, empty, in); > > if (n < 0) > > return n; > > + if (!key->len) > > + return -1; > > It is curious that this gets a different error out of the same > sequence, i.e. decode-key did not return an error but the length of > the key happens to be 0, not FORMAT_ERROR. fixed. > > --- a/reftable/writer.c > > +++ b/reftable/writer.c > > @@ -240,14 +240,13 @@ static int writer_add_record(struct reftable_writ= er *w, > > > > writer_reinit_block_writer(w, reftable_record_type(rec)); > > err =3D block_writer_add(w->block_writer, rec); > > - if (err < 0) { > > + if (err =3D=3D -1) { > > /* we are writing into memory, so an error can only mean = it > > * doesn't fit. */ > > err =3D REFTABLE_ENTRY_TOO_BIG_ERROR; > > goto done; > > } > > > > - err =3D 0; > > Is this "doesn't fit" related to "we catch 0-length keys", or an > unrelated fix was included in this step by "rebase -i" mistake? We don't want to reinterpret API_ERROR (from block_writer_add) as ENTRY_TOO_BIG_ERROR, so we have to tweak the condition here. --=20 Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian