From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75AADC432BE for ; Tue, 31 Aug 2021 04:41:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 431F9601FD for ; Tue, 31 Aug 2021 04:41:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230076AbhHaEmL (ORCPT ); Tue, 31 Aug 2021 00:42:11 -0400 Received: from pb-smtp21.pobox.com ([173.228.157.53]:50492 "EHLO pb-smtp21.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229579AbhHaEmL (ORCPT ); Tue, 31 Aug 2021 00:42:11 -0400 Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 72BF5151C9A; Tue, 31 Aug 2021 00:41:16 -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; s=sasl; bh=zfP/qH/qLre0GiuVR2cWbfXLwOsJDUqouOFg0n ZT9OY=; b=THr4e2JAaJtswUvxKRw3hL+BXgo+4s+4JbZ8K6bGFMYCvclV/URHxc Z30eTHrOqTtEFX3OTT79B9ePKBQ4IvuIMZx4WhemUzX8uAlZk196nIpGUvKlkmB3 MociXp9xGMkdmMRU6ezL0fYKvGWx2jlfFLwjv2qrm4gX5zKYchyo8= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 6B0FE151C99; Tue, 31 Aug 2021 00:41:16 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.74.116.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id B44E1151C98; Tue, 31 Aug 2021 00:41:13 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Elijah Newren Cc: Yuri , Git Mailing List Subject: Re: Git re-creates newly added directory when it is pushed References: Date: Mon, 30 Aug 2021 21:41:12 -0700 In-Reply-To: (Elijah Newren's message of "Mon, 30 Aug 2021 19:15:58 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: ABFA2AEA-0A15-11EC-923A-9BA3EF469F85-77302942!pb-smtp21.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Elijah Newren writes: >> This is one of the reasons why "rebase" (especially "rebase -i") may >> want to insist starting at the top-level of the working tree, like >> "git bisect" does. Because running the command from a subdirectory >> works most of the time until it doesn't, people tend to complain why >> they should go up to the top-level before they can run the command. >> >> And this is why---it causes end-user confusion. > > Makes sense to me; I'll submit a patch. Well, but not too hastily. It is one thing to be firm and resist those who want to loosen "git bisect" to allow it to start in a subdirectory, in order to keep protecting the innocent who are already protected with the current safeguard from confusion. It is entirely a different thing to tighten "git rebase" retroactively to break those who are used to see the command start in a subdirectory. The potential confusion that is caused may be the same between commands, but either change can potentially hurt existing users. I hope your patch would serve as a good discussion starter. We may end up loosening "git bisect" to expose our users to possible confusion, the same one that already exists for users of "git rebase", in the name of consistency, and it might even turn out to be a good change. Or not. In any case, it would be a good opportunity to force people thoroughly think things through. Thanks.