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-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 25CD81F55B for ; Thu, 21 May 2020 19:50:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729754AbgEUTuU (ORCPT ); Thu, 21 May 2020 15:50:20 -0400 Received: from pb-smtp21.pobox.com ([173.228.157.53]:56056 "EHLO pb-smtp21.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728273AbgEUTuT (ORCPT ); Thu, 21 May 2020 15:50:19 -0400 Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 9661CBD391; Thu, 21 May 2020 15:50:18 -0400 (EDT) (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=DpZVszsunQdxDTqGZC6Azn20o8g=; b=KgvORq WK7omkFtubl8UiaGQeN0CjLk437lGqHmSq7WUCFzIAawiezWSwF8/2GGp9Bhh4VX lOejUw9oMndnen4VzpKQ7h4gVRTZCuUV2KFtGFSKMEU1G2nmx0m+BGZ2yoyXkczV z1lpFTyYL55bl8UrTBiLeytAfdcmPRFgrHKSU= 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=hlSnAAxlv6L5Ltdk+vmIiSAJRpPW0joh UdZb5gp8tI8q6P3cSpfQGVn3GeMmtCEFlg3tOfoBlBnkdMnL5h/Uo54J5eFHoRTW +mpD8vcXO+imx2Cewb2IxTCcsj05TCmPf37hx+Oa/gSwavKzyeIfELVeT4+QcnRc eDOKqpqh/Uw= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 8D6A8BD390; Thu, 21 May 2020 15:50:18 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [35.196.173.25]) (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 CC16FBD38F; Thu, 21 May 2020 15:50:15 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Denton Liu Cc: Shourya Shukla , git@vger.kernel.org, christian.couder@gmail.com, kaartic.sivaraam@gmail.com, congdanhqx@gmail.com, sunshine@sunshineco.com, Christian Couder Subject: Re: [PATCH v3] submodule: port subcommand 'set-branch' from shell to C References: <20200521163819.12544-1-shouryashukla.oo@gmail.com> <20200521190329.GB615266@generichostname> Date: Thu, 21 May 2020 12:50:13 -0700 In-Reply-To: <20200521190329.GB615266@generichostname> (Denton Liu's message of "Thu, 21 May 2020 15:03:29 -0400") 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: 4AB105DA-9B9C-11EA-BE2A-8D86F504CC47-77302942!pb-smtp21.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Denton Liu writes: >> Sorry, I may have missed the previous rounds of discussion, but the >> comment adds more puzzles than it helps readers. "is currently not >> used" can be seen from the code, but it is totally unclear why it is >> not used. Is that a design decision to always keep quiet or always >> talkative (if so, "suppress output..." is not a good description)? >> Is that that this is a WIP patch that the behaviour the option aims >> to achieve hasn't been implemented? Is it that no existing callers >> pass "-q" to the scripted version, so there is no need to support >> it (if so, why do we even accept it in the first place)? Is it that >> all existing callers pass "-q" so we need to accept it, but there is >> nothing we need to make verbose so the variable is not passed around >> in the codepath? > > As the original author of the shell code, I had it accept -q because, > with the other subcommmands, you can pass -q either before or after the > subcommand such as > > $ git submodule -q sync > > or > $ git submodule sync -q > > and I wanted set-branch to retain that behaviour even though -q > ultimately doesn't affect set-branch at all since it's already a quiet > command. OK, so "we accept -q for uniformity across subcommands, but there is nothing to make less verbose in this subcommand" is the answer to my question. That cannot be read from "... is currently not used"; especially with "currently", I expect that most readers would expect we would start using it in the (near) future, and some other readers would guess that something used to be talkative and we squelched it using the option but there no longer is such need because that something is now quiet by default and there is no option to make it talkative.