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=-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,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE 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 56B771F45E for ; Fri, 14 Feb 2020 15:03:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729580AbgBNPDj (ORCPT ); Fri, 14 Feb 2020 10:03:39 -0500 Received: from pb-smtp1.pobox.com ([64.147.108.70]:50682 "EHLO pb-smtp1.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729568AbgBNPDi (ORCPT ); Fri, 14 Feb 2020 10:03:38 -0500 Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 7AC6745E9A; Fri, 14 Feb 2020 10:03:37 -0500 (EST) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=K37wikhh9NelTt+E+3qkeNVne3M=; b=RJ0DjB 2WInzFWghnPVyHFamepX8zuv1g7UEyPMIaWUw9+GQoVUBjxoDpywHElKKzduGb0b 8hhXQKFYgmcdYnrlPG9upsw1NDaUDHn06ivIhnryfj67qLkQfb01EOZhESWmBtbE ua3JjusiGYzK3XE6lKqjhWyIPZ5qX+GfNyn3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=EW2pK4yrZofRMppnxNvJw1hpXO9H2Ogu 2RyeFFOivQRhIv56SAlLtSkSEtevZbaOuRug8KEt9+GWEZeQkJyby3CDs9eF8hTJ lDhcot4tSt4yYB9t9zG36x3iQD5mwa/qZRRJcN32I9+kXAu6UlmbgaWYIvfBLOLj rr8GsHIlvEM= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 72A6445E99; Fri, 14 Feb 2020 10:03:37 -0500 (EST) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.76.80.147]) (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 B08AD45E98; Fri, 14 Feb 2020 10:03:36 -0500 (EST) (envelope-from junio@pobox.com) From: Junio C Hamano To: Johannes Schindelin Cc: Hariom Verma via GitGitGadget , git@vger.kernel.org, Hariom Verma Subject: Re: [PATCH 2/3] t5509: initialized `pushee` as bare repository References: Date: Fri, 14 Feb 2020 07:03:35 -0800 In-Reply-To: (Johannes Schindelin's message of "Fri, 14 Feb 2020 12:59:06 +0100 (CET)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 2D26B7D8-4F3B-11EA-9615-C28CBED8090B-77302942!pb-smtp1.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Johannes Schindelin writes: >> Can patch 3/3 be split into two, > > I actually don't think so. The `refs_resolve_unsafe()` function simply > ... > In other words, a fix for one bug would be a fix for the other, and > (probably) vice versa. What mislead me was the way this step presented itself. It sounded as if the primary (and possibly the only) thing the series wanted to fix was to make .denyCurrentBranch pay attention to other worktrees, and while fixing that, it broke as collateral damage a "feature" that denyCurrentBranch allows an unborn branch to be updated no matter what and called it a bugfix when it was not a bug. If the series is fixing two bugs, perhaps 2/3 can first fix it for a primary worktree case by seeing what HEAD symref for the primary worktree points at is the target of a push without iterating over all the worktrees, have the test change in 2/3 (i.e. "fixing the 'unborn' case revealed a wrong expectation in an existing test"), and a couple of new tests to see what a push from sideways would do to an unborn branch that is checked out in the primary worktree when .denyCurrentBranch is and isn't in effect. Then 3/3 can use the same logic to see if one worktree is OK with the proposed ref update by the push used in 2/3 (which no longer uses refs_resolve_unsafe()') to check for all worktrees. The new tests introduced in 2/3 would be extended to see what happens when the unborn branch getting updated by the push happens to be checked out in a secondary worktree. That would have avoided misleading this reader. Thanks.