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=-3.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [IPv6:2604:1380:45d1:ec00::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id DA0BA1F4B8 for ; Wed, 24 Jan 2024 17:26:24 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=pobox.com header.i=@pobox.com header.a=rsa-sha256 header.s=sasl header.b=vlIF5bCm; dkim-atps=neutral Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 184DF1C26109 for ; Wed, 24 Jan 2024 17:26:24 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3FE0012A174; Wed, 24 Jan 2024 17:21:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b="vlIF5bCm" Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8BA6512A15B for ; Wed, 24 Jan 2024 17:21:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=173.228.157.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706116901; cv=none; b=gMwIetsk5rKJwH3hLjenG0BxL4k4le9/j0gxE/l5vUsDKRvOpeYWXbrjpz5d/KM5+go8oqnu5CuH9GQ+A4dx21OKyrhmWzT24yst20Xxv985sKlBn6wFWfGq6Xcdpx4zuJ5UQBr16dMyjOOzW3XOxi78piAXVX9hHl6tgNA4oeU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706116901; c=relaxed/simple; bh=IioAFM+C+Y324wT+leWSE/PREXtviccOitBWHkKrxSg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=AJ/9rIb0mcT8wLxplce/ywLRCkAJ90CP5rX4Tm4k28Ksb2wqgRM5hqHtRJ8Ul2L34szN0yzVD9Fnirq/pIHFk2tPaNdsZ++2Q/bda3jrblubnNlbmybID3v4oU7gEfvHErJBUGILUu9zbWAMG4oWxU04gw6JasuLTL7dc1PTnqU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=pobox.com; spf=pass smtp.mailfrom=pobox.com; dkim=pass (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b=vlIF5bCm; arc=none smtp.client-ip=173.228.157.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=pobox.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pobox.com Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id C649A23D4C; Wed, 24 Jan 2024 12:21:38 -0500 (EST) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=from:to:cc :subject:in-reply-to:references:date:message-id:mime-version :content-type; s=sasl; bh=IioAFM+C+Y324wT+leWSE/PREXtviccOitBWHk KrxSg=; b=vlIF5bCmcYCWNM/L81bpsGoZFoicX7sCPmsholitwnyoIGtiwA1v8I yePvFI2MhC167VfoA//BcXEHb4lJ71VTuHIdMFqhBtvDRqIkRiCG8oUDGkDIb014 zMZ3ujbvo03JfLXkPBsB/Y1Dha7WqQtbRh/suhlqIAR0nu1rivgjE= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id BEE7A23D4B; Wed, 24 Jan 2024 12:21:38 -0500 (EST) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.125.200.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 84F3023D43; Wed, 24 Jan 2024 12:21:33 -0500 (EST) (envelope-from junio@pobox.com) From: Junio C Hamano To: Sergey Organov Cc: Elijah Newren , git@vger.kernel.org Subject: Re: what should "git clean -n -f [-d] [-x] " do? In-Reply-To: <87plxr3zsr.fsf@osv.gnss.ru> (Sergey Organov's message of "Wed, 24 Jan 2024 11:23:32 +0300") References: <87a5ow9jb4.fsf@osv.gnss.ru> <87plxr3zsr.fsf@osv.gnss.ru> Date: Wed, 24 Jan 2024 09:21:32 -0800 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 055D37CE-BADD-11EE-B7AC-F515D2CDFF5E-77302942!pb-smtp20.pobox.com Sergey Organov writes: > Whereas obsoleting second -f in favor of new --nested-repo might be a > good idea indeed, I believe it's still a mistake for "dry run" to > somehow interfere with -f, sorry. No need to be sorry ;-) I actually think the true culprit of making this an odd-man-out is that the use of "-f" in "git clean", especially with its use of the configuration variable clean.requireForce that defaults to true, is utterly non-standard. The usual pattern of defining what "-f" does is that the "git foo" command without any options does its common thing but refuses to perform undesirable operations (e.g. "git add ." adds everything but refrains from adding ignored paths). And "git foo -f" is a way to also perform what it commonly skips. In contrast, with clean.requireForce that defaults to true, "git clean" does not do anything useful by default. Without such a safety, "git clean" would be a way to clean expendable paths, and "git clean -f" might be to also clean precious paths. But it does not work that way. It always requires "-f" to do anything. Worse yet, it is not even "by default it acts as if -n is given and -f is a way to countermand that implicit -n". It is "you must give me either -f (i.e. please do work) or -n (i.e. please show what you would do) before I do anything". $ git clean fatal: clean.requireForce defaults to true and neither -i, -n, nor -f given; refusing to clean Given that, it is hard to argue that it would be a natural end-user expectation that the command does something useful (i.e. show what would be done) when it is given "-f" and "-n" at the same time. What makes this a rather nonsense UI is the fact that "-f" does not work the way we would expect for this command.