From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16776 invoked from network); 1 Oct 2023 20:17:37 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 1 Oct 2023 20:17:37 -0000 Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Sun Oct 1 16:14:14 -0400 2023 Received: from stockyard.lan ( [172.56.165.128]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 583055e3 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Sun, 1 Oct 2023 13:14:11 -0700 (PDT) Message-ID: To: 9front@9front.org Date: Sun, 01 Oct 2023 16:14:09 -0400 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: rich-client XMPP app-scale STM-oriented pipelining-oriented module-oriented control Subject: Re: [9front] [PATCH] git: add missing usages for subcommands Reply-To: 9front@9front.org Precedence: bulk Quoth ori@eigenstate.org: > Quoth unobe@cpan.org: > > Quoth ori@eigenstate.org: > > > these were intentionally ommitted; you shouldn't need to use > > > them. They exist for scripts like 'git/commit', 'git/push', and > > > 'git/pull'. > > > > Thanks, Ori. I didn't realize that programs existing in the > > distribution shouldn't be documented. > > > > Two follow-ups: > > > > 1) Is that something that is standard and I've just never realized it? > > Not sure about 'standard'; it's a judgement call. > > I wouldn't mind having some form of documentation, but > putting them in the main git manpage just confuses the > user on how to do things, IMO. > > It's the same reason that debug flags are typically not > documented; if you're interacting with them, you're > typically already in the code. > > > 2) I didn't include git/hist in the doc patch: that's a "shouldn't > > need to use" program as well? > > No, that's one that's quite useful; it's basically > git blame on a budget (because it's honesty a pain > in the ass to implement 'blame'. > git/repack may also make sense to document; it's kind of rarely needed maintenance, but it *may* make sense for users to use -- though it's just as much a test program for the pack generation logic.