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: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 3A7961F8C6 for ; Wed, 30 Jun 2021 21:14:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234112AbhF3VQ3 (ORCPT ); Wed, 30 Jun 2021 17:16:29 -0400 Received: from pb-smtp1.pobox.com ([64.147.108.70]:61857 "EHLO pb-smtp1.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233777AbhF3VQX (ORCPT ); Wed, 30 Jun 2021 17:16:23 -0400 Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 3CF58DC7EB; Wed, 30 Jun 2021 17:13:53 -0400 (EDT) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=0NShmekJHmN/ UgIzA5Bi6IC0YsPun2GeLrhz/eD2RVI=; b=EpQT3nqDfXEXq3cAYip+Ancus8bN dv0aAh/B9TpScEBM+fVlgn34z1ZTJkr0hQCfKqFQhBBa7LaiutIhlI9rXOLLzUxZ lLHm4BYYhWXVZ2wO6vf+KskiVI+VUo+i984BZafdpAg4d8CIlSUPrGqroIMoH1HS 6pbG3YPYSyhgocE= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 34113DC7EA; Wed, 30 Jun 2021 17:13:53 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.74.3.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id B028FDC7E9; Wed, 30 Jun 2021 17:13:52 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason Cc: git@vger.kernel.org, Johannes Schindelin Subject: Re: [PATCH v4 2/3] bundle doc: split out open v.s. closed discussion from References: Date: Wed, 30 Jun 2021 14:13:52 -0700 In-Reply-To: (=?utf-8?B?IsOGdmFyCUFybmZqw7Zyw7A=?= Bjarmason"'s message of "Wed, 30 Jun 2021 11:16:27 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Pobox-Relay-ID: 124A2682-D9E8-11EB-8427-8B3BC6D8090B-77302942!pb-smtp1.pobox.com Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason writes: > Split out the discussion of why you should or should not create "open > bundles" into a new section, away from the discussion of our handling > of the rev-args syntax. I changed my mind about this part. * There is no option to create a bundle with one or more prerequisite commits with a non-thin packfile as its payload part. So "THIN BUNDLE" is an unnecessary new jargon and concept that does not help readers at all, because there is no "thick bundle" that has prerequisite commits. Let's not introduce such a new word. * We do not call DAG in our history with bottom end (i.e. a range with one or more uninteresting commits) an "open history". Let's not invent the words, "open" vs "close", to describe the history recorded in a bundle, either. We do already have an appropriate phrase we can use to explain what you wrote in open/close section: "the prerequisite commits" (find it in the description of "verify" subcommand) and that has been a concept well understood for a long time, ever since 2e0afafe (Add git-bundle: move objects and references by archive, 2007-02-22) introduced the bundle format. Let's use that phrase, instead of inventing a new word. In short, there are two kinds of bundles. - A bundle with one or more prerequisite commits can only be extracted in a repository that already has all these prerequisite commits and the history behind them, and "git bundle verify" is an easy way to check if your recipient repository has the prerequisites. The payload in such a bundle is always a thin packfile, but such a technical detail does not concern readers. - A bundle without any prerequisites can be extracted into anywhere, even into an empty repository, or cloned from it. And that should be sufficient to base your new paragraph(s). Sorry for having made a potentially confusing comment earlier. What I said about open vs thin was technically correct (i.e. there wasn't fundamental reason why a bundle with prerequisites MUST use a thin pack as its payload---we designed it that way because such a bundle MUST be extracted in a repository with these prerequisites present, hence it was OK to assume that a --fix-thin would work while extracting such a bundle), but it is irrelevant in practice because you cannot ask for a thick packfile to be created when creating such a bundle anyway. Thanks.