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: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-11.6 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,USER_IN_DEF_DKIM_WL shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 527561F45E for ; Wed, 12 Feb 2020 22:13:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728447AbgBLWNl (ORCPT ); Wed, 12 Feb 2020 17:13:41 -0500 Received: from mail-qv1-f67.google.com ([209.85.219.67]:36270 "EHLO mail-qv1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727564AbgBLWNl (ORCPT ); Wed, 12 Feb 2020 17:13:41 -0500 Received: by mail-qv1-f67.google.com with SMTP id db9so1707217qvb.3 for ; Wed, 12 Feb 2020 14:13:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mAzU2geDuLVagJ9IhS2Z49g1pIeYgci4zP6GpHOUA6g=; b=HAlvct5owelcxDRlhFbeiECgP572btfnj0X3WSrJC2M8mY7jjJXkn2YkHsDM5lHBu7 2QrYNnS7Qzrqu0KTGDRZDNP439tPsSKUBmy3LDurXcp66YcXbMvRQ3CYcyx/15BlY5Iv W0X+mG3weAsmlGFEOyLVmCLKq6fAx1HCGMkeX5R+Pfc6MR3EGv2Tsq8ZajDpa8z5u8Od TzI72i1b6M07wcrChgmDT8oQl4o7Xi2p/sViX7P4vrPe0Cvyt+An/nraWR7NEb7ShQTq Qqe8IPT6bVOXXM5RtEMIqcwmRa/L8wiDCyriaRq3f0zJo79ftKLNswQidCnNPSepjHda IlgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mAzU2geDuLVagJ9IhS2Z49g1pIeYgci4zP6GpHOUA6g=; b=qVfmxxcwMvvfDeN3aame2u2pOtU7IIe35CsuO1WUE85bsFuWn+hX15X9d0U/hyCiNz RBEjr0iaoHsHYF3qNR16/3UQ4DXF0atGXoF/2DJeYgWx6bO8cnNkU/s7VYYxeDtVjUr0 nhdzrcuvR5oaAJVZdM2mA4MVQmEJUK8QcchkODjE94ANIvx5x1/WIFABSsCmfk0Rl4tY Ck895n3+Fg+M1bZrLf4gbut+08jVBhjimitRFac7RPYPruFWEx04wooJVisQKsBhrgtY v+lv26u2fVqXe5i7LmKwrrX6Iw4/Gu6cXDXt58X7YC0PBSL6bTBqBhBdJxvqUgl63TPs wRBQ== X-Gm-Message-State: APjAAAU9d+s8P/0323WalKDv9iAztUfaQNft6Y58cC2sc2qOWc98hFf8 OAjM5qUInevYECxOAQFLDAZ1Nm6ENDJg9Yu6oCgxIC71B9A= X-Google-Smtp-Source: APXvYqxiCdqEXnmvcfqf04yXUFRQj8Hu0lHp+/g9w0HGZ1e/lEGi1ylUbLIlwrrYv8krY14cZAduco7GCn0NXNHZYo8= X-Received: by 2002:ad4:4511:: with SMTP id k17mr8743820qvu.135.1581545619973; Wed, 12 Feb 2020 14:13:39 -0800 (PST) MIME-Version: 1.0 References: <20200131221800.240352-1-masayasuzuki@google.com> <20200207204225.123764-1-masayasuzuki@google.com> In-Reply-To: From: Masaya Suzuki Date: Wed, 12 Feb 2020 14:13:29 -0800 Message-ID: Subject: Re: [PATCH v3] doc: describe Git bundle format To: Junio C Hamano Cc: Git Mailing List Content-Type: text/plain; charset="UTF-8" Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Fri, Feb 7, 2020 at 5:49 PM Junio C Hamano wrote: > > Masaya Suzuki writes: > > > Yes. The reason that I've been trying to check the semantics of the > > prerequisites is that I DO recognize that this is possible > > format-wise. I'm not sure if this Git implementation can create such > > bundles, but format-wise such bundles can be created. > > Yeah, now I get it. > > The problem is *not* that v2 format "cannot represent a shallow > clone repository", but is that there is nothing that prevents a > bundle in v2 format from depending on objects behind (not just at) > the shallow boundary, making it impossible for a reader to guarantee > that a bundle with prereqs can be used to create an equivalent > shallow repository with shallow boundary at the same place as > prereqs. IOW, bundle with prereqs in the v2 format allows more > objects to be omitted than an equivalent shallow repository omits, > because prereqs and shallow cutoff points mean different things. Yes. So, I think it's better to say prereqs and shallow boundaries are different. > While we are at it, I suspect that with reachability bitmap, a "git > fetch" that updates a history up to commit A to a new history up to > commit B can omit more objects than what is directly reachable from > the commit A. That is, if A's direct child (call it C) is a commit > that reverts A, a blob in A's tree won't be in the bundle (because A > is a prereq), but the blob at the same path in C is the same blob as > the blob at the same path in A's parent (that is what it means for > that A's direct child to be a revert of A). In the normal > enumeration based on object-walk to decide which objects to send, > such a blob in C will be included in the pack, That's interesting. I have never looked CGit's implementation, but I think JGit would omit those objects. (At least that was my understanding. Not confirmed with the code.) Anyway. Is it OK with adding this small note on "prereq is not a shallow boundary"? In practice, there are not many Git implementations that handle Git bundles, so it's not that big deal as long those few implementers recognize this, but this document is meant for those implementers.