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: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-4.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_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 C9DCD1F8C6 for ; Tue, 14 Sep 2021 21:49:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234656AbhINVui (ORCPT ); Tue, 14 Sep 2021 17:50:38 -0400 Received: from pb-smtp1.pobox.com ([64.147.108.70]:60400 "EHLO pb-smtp1.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233952AbhINVuh (ORCPT ); Tue, 14 Sep 2021 17:50:37 -0400 Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B9546DF3B7; Tue, 14 Sep 2021 17:49:19 -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:message-id:mime-version:content-type; s=sasl; bh=tTGWhWgqkaftQQRkBR6o9dz8T57vFUHGgMzTwfa/WBg=; b=FsPd ehpJxSQh+LuDf0hroDp//UBEeCzmyfXFFjjRw068aA5GU+DIA34U3o4EaIXPRP14 bWR7gNNmKiuOdXesSNZQZRvCHE89fB0aLTI+SsaKiCgl6zd0LDg680g12VA8SyIF eeV8ajrhrb3MB3oTyc9mjki+xUMDJzW1nqkdDSs= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B131DDF3B5; Tue, 14 Sep 2021 17:49:19 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.73.10.127]) (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 DEB5BDF3B4; Tue, 14 Sep 2021 17:49:18 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Johannes Schindelin Cc: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , Johannes Schindelin via GitGitGadget , git@vger.kernel.org, Derrick Stolee , Eric Sunshine , Elijah Newren , Bagas Sanjaya Subject: Re: Train station analogy, was Re: [PATCH v3 00/15] [RFC] Upstreaming the Scalar command References: <87r1dydp4m.fsf@evledraar.gmail.com> <87ilz44kdk.fsf@evledraar.gmail.com> <87mtofnzv1.fsf@evledraar.gmail.com> Date: Tue, 14 Sep 2021 14:49:18 -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: 9CFDA742-15A5-11EC-AF59-62A2C8D8090B-77302942!pb-smtp1.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Junio C Hamano writes: > But at least I view it as a step that needs to happen sometime > between now and at the end. I do not yet have an opinion on > which one is more pleasant, between (1) having to deal with a > single Makefile that needs to be aware of two different locations > *.[ch] lives in, and (2) having to deal with two Makefiles that > duplicates definitions and risks them needlessly diverging. FWIW, I am leaning towards the latter, with the assumption that this may take more than a cycle to cook in contrib/. Adding the Makefile bits to the top-level and keeping the topic in 'next' means all the topics that pass the pipeline will need to be written in such a way that its Makefile change works well with and without the unified Makefile bits from this topic, an additional burden on other topics this topic would impose. So it is understandable to want to keep the changes to the top-level Makefile to the minimum, even if it may mean that it requires more effort in the end to clean things up when the topic graduates. An alternative would be to bypass the contrib/ phase and start as a new subcommand that is first-class citizen from day one and let it spend as much time as it needs to mature. It would burden the topics that pass the pipeline while this is cooking the same way as having a unified build procedure in the top-level Makefile, of course, though.