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=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, 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 448011F5AE for ; Tue, 27 Apr 2021 20:41:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235803AbhD0UmR convert rfc822-to-8bit (ORCPT ); Tue, 27 Apr 2021 16:42:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235412AbhD0UmQ (ORCPT ); Tue, 27 Apr 2021 16:42:16 -0400 Received: from mav.lukeshu.com (mav.lukeshu.com [IPv6:2001:19f0:5c00:8069:5400:ff:fe26:6a86]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D685C061574 for ; Tue, 27 Apr 2021 13:41:32 -0700 (PDT) Received: from lukeshu-dw-thinkpad (unknown [IPv6:2601:281:8200:26:4e34:88ff:fe48:5521]) by mav.lukeshu.com (Postfix) with ESMTPSA id B39B380590; Tue, 27 Apr 2021 16:41:23 -0400 (EDT) Date: Tue, 27 Apr 2021 14:41:22 -0600 Message-ID: <87k0ona2a5.wl-lukeshu@lukeshu.com> From: Luke Shumaker To: Junio C Hamano Cc: Eric Sunshine , Luke Shumaker , Git List , Avery Pennarun , Charles Bailey , Danny Lin , "David A .\ Greene" , David Aguilar , Jakub Suder , James Denholm , Jeff King , Jonathan Nieder , =?UTF-8?B?Tmd1eeG7hW4g?= =?ISO-8859-1?Q?Th=E1i_?= =?UTF-8?B?Tmfhu41j?= Duy , Roger L Strain , Techlive Zheng , Luke Shumaker Subject: Re: [PATCH 04/30] subtree: t7900: use consistent formatting In-Reply-To: References: <20210423194230.1388945-1-lukeshu@lukeshu.com> <20210423194230.1388945-5-lukeshu@lukeshu.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Tue, 27 Apr 2021 01:17:38 -0600, Junio C Hamano wrote: > > Eric Sunshine writes: > > >> +check_equal () { > >> test_debug 'echo' > >> test_debug "echo \"check a:\" \"{$1}\"" > >> test_debug "echo \" b:\" \"{$2}\"" > >> - if [ "$1" = "$2" ]; then > >> + if [ "$1" = "$2" ] > >> + then > > > > We prefer `test` over `[`, so it might make sense to update that, as > > well, along with these other style cleanups. > > If I were working on this, I wouldn't bother. In this case, it's not just about consistency with git-core, it's about consistency within contrib/subtree; there were just 2 or 3 places where it used `[` instead of `test`. > If Luke is volunteering to take over its maintainership, it would be > appreciated by its users. It has been in the "abandonware" status > for too long. I think I am volunteering. We have been using git-subtree increasingly heavily at Ambassador Labs (née Datawire) for about 2 years now, and I don't see that changing. What I'm doing now is trying to get >2 years of accumulated patches in to a submittable state (a lot of the patches were bad; for instance on my main branch `git subtree add` is broken, but that's fine, because you don't use `add` all the time like you do `split` or `merge`, but that's something I need to fix before submitting it). Assuming that we're going to continue being heavy users of it, and are going to continue to patch issues with it, I'd rather let that live upstream rather than telling all of my coworkers to get it from . With a recent change in project scheduling, I anticipate that I'll have bandwidth to be able to handle that. (It's what's giving me adequate time to work through this pile of existing patches, anyway.) What does being a maintainer consist of? Are there standups that I should join? > As far as I am concerned, contrib/subtree has always been treated as > a borrowed code [*] that is written in a dialect of shell that is > different from what our scripts are written in, and there are too > many style differences (I wouldn't call them violations---nobody has > expected the code there to follow our style, or attempted to enforce > our style there) to bother coercing. > > [Footnote] > > * ... as opposed to a properly maintained part of the git-core > proper. Elsewhere in the thread, you suggested that subtree be taken out of git.git, and live as a standalone project. I'm not entirely opposed to that, but 1. I'm not sure how whoever picks it up (me) establishes their git-subtree as the "real" subtree (get a blessing from Avery?). 2. I think a lot of the reason why more people don't use git-subtree is that the core 'split' operation doesn't quite work reliably (and also it can be quite slow), and so it doesn't get recommended. I would like nothing more than to improve the 'split' reliability to where it does start to gain adoption, to where we can think about it graduating from contrib/ to git-core. 3. Many systems (Arch Linux and macOS, at least) give users git-subtree as part of the stock Git install. If I'm interested in growing git-subtree adoption, I'd be a fool to give that up :) On the other hand, I think that in the long-ish term git-subtree wants to be rewritten in a better-suited language. My personal inclination would be Go, but if I ever want it to graduate to git-core, it'd have to be C, huh? -- Happy hacking, ~ Luke Shumaker