From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-2.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 4CE1D1F55F for ; Mon, 4 Sep 2023 15:29:34 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=klerks.biz header.i=@klerks.biz header.a=rsa-sha256 header.s=google header.b=Adr2/Euq; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351482AbjIDP3f (ORCPT ); Mon, 4 Sep 2023 11:29:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351031AbjIDP3e (ORCPT ); Mon, 4 Sep 2023 11:29:34 -0400 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3DE1CC4 for ; Mon, 4 Sep 2023 08:29:28 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-500cfb168c6so2645697e87.2 for ; Mon, 04 Sep 2023 08:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klerks.biz; s=google; t=1693841367; x=1694446167; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+/Pu6ibvopOu3hb6xFCMQvx3iImNE5F+c6APp+QOGLI=; b=Adr2/EuqL2ClVFcuF8xZEL9H3kGvE0WYJ90vQdtilb0eG9KOwt+Pbo9/ww1mB42K4u M37vGF79in37uLrmNxcP7T+k6x8eH3d6LjTBigvXgv4CdyMuQLARaaXt28rhiNAQAxek h41d4lrqPIHOlDlBFxETvvRk6DvR8jzQEmvjw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693841367; x=1694446167; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+/Pu6ibvopOu3hb6xFCMQvx3iImNE5F+c6APp+QOGLI=; b=b7KlFIW+mBqpM/MU0EFzcOptuIw0HAo7HaRV+0b3f74U2vx5ZABd+O4ULR1QardypQ CuS/kLWHNVfUmyO7u6vNaodovcagCu4YKjUM52sVY3k+Orei6IRifhTSvK0GwVU8DQeT Wdi8Tcj44BHRtZ4ncb9DJ3cnmyaVxtXYcez8BkelBdlvrXETMQgJ4G/OlAXXZd2PXU+v SPAccDjSyyhIaepFVjaFRthe3X7BwA6bMpNdEyWejT53Cp8bL+ZetGoSzlZ4GX1uvVY+ 8mFUyXS/h8Kg3gVpt7AeukSwAMWwARtvFAon+2KRbAbc26c6H/AsVGko1vigJq02HXWN dq/Q== X-Gm-Message-State: AOJu0YwY25LuKoWSjWGih6tB2sb1Gv0LVmghl9C3Nd4Y9sYjN4waspxY DuqTH1ZgUpDqpphQlx1jALxYzUiTNrzMGbJEclcrNaDgp+0C6gqQzypJgw== X-Google-Smtp-Source: AGHT+IGkfmV72Gj0t2AS8rxVsc80LSPrTAejgs/aJ6gN9NwDx/X4tYxIqBmLgH8f+1YnAdORBQQUuMr5jCDF1T0Z9c8= X-Received: by 2002:a05:6512:3b2c:b0:500:d970:6541 with SMTP id f44-20020a0565123b2c00b00500d9706541mr9044354lfv.39.1693841366642; Mon, 04 Sep 2023 08:29:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tao Klerks Date: Mon, 4 Sep 2023 17:29:16 +0200 Message-ID: Subject: Re: Is "bare"ness in the context of multiple worktrees weird? Bitmap error in git gc. To: git Cc: Johannes Schindelin , Taylor Blau , Patrick Steinhardt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Mon, Sep 4, 2023 at 4:59=E2=80=AFPM Tao Klerks wrote: > > > It seems, to me, that "my setup" makes a lot more sense than what you > end up with when you use "--separate-git-dir", and that the behavior > there predates the current "mutual reference" model of > worktrees-to-their-repo. If "my" use of "core.bare" in the example > above is sound - then should the implementation of > "--separate-git-dir" be changed to produce a bare repo with a > "worktrees" folder, like you get if you clone bare and add a worktree > in two separate steps? > And to confuse matters further, I just stumbled across https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir - I don't understand when you would want to use that vs, again, a bare repo with one or more worktrees properly attached via two-way references, their own indexes, their own reflogs, etc. Is it the case that this contrib script predates the current "git worktree" support?