From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#57400: 29.0.50; Support sending patches from VC directly Date: Fri, 14 Oct 2022 09:50:38 +0300 Message-ID: <83sfjq99vl.fsf@gnu.org> References: <84v8qgn1z9.fsf@iki.fi> <87sfljmgwz.fsf@posteo.net> <87y1twvima.fsf@posteo.net> <84sfk2p846.fsf@iki.fi> <87h70i9ntt.fsf@posteo.net> <87edvl6vbj.fsf@gmail.com> <8735c1nn3y.fsf@posteo.net> <877d1d6rcy.fsf@gmail.com> <867d1cjc8w.fsf@mail.linkov.net> <87o7unkggk.fsf@posteo.net> <86edvids93.fsf@mail.linkov.net> <87zge52nx0.fsf@posteo.net> <86sfjvqz68.fsf@mail.linkov.net> <87edvecg45.fsf@posteo.net> <86r0ze2ldb.fsf@mail.linkov.net> <871qrchzli.fsf@posteo.net> <86tu471vhq.fsf@mail.linkov.net> <875ygnjyp0.fsf@posteo.net> <87mt9zii8w.fsf@posteo.net> <831qrba2g1.fsf@gnu.org> <87ilknidkv.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6567"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rpluim@gmail.com, 57400@debbugs.gnu.org, ane@iki.fi, juri@linkov.net To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 14 08:52:24 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ojEYR-0001XP-KM for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Oct 2022 08:52:23 +0200 Original-Received: from localhost ([::1]:40670 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojEYQ-0003Ce-5P for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Oct 2022 02:52:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58674) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojEY7-0003BX-57 for bug-gnu-emacs@gnu.org; Fri, 14 Oct 2022 02:52:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36532) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ojEY6-0000MT-T4 for bug-gnu-emacs@gnu.org; Fri, 14 Oct 2022 02:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ojEY6-0006ES-J0 for bug-gnu-emacs@gnu.org; Fri, 14 Oct 2022 02:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Oct 2022 06:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57400 X-GNU-PR-Package: emacs Original-Received: via spool by 57400-submit@debbugs.gnu.org id=B57400.166573026523868 (code B ref 57400); Fri, 14 Oct 2022 06:52:02 +0000 Original-Received: (at 57400) by debbugs.gnu.org; 14 Oct 2022 06:51:05 +0000 Original-Received: from localhost ([127.0.0.1]:35610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojEXB-0006Cu-45 for submit@debbugs.gnu.org; Fri, 14 Oct 2022 02:51:05 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47788) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojEX7-0006CN-IF for 57400@debbugs.gnu.org; Fri, 14 Oct 2022 02:51:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49042) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojEX0-0000Fm-DE; Fri, 14 Oct 2022 02:50:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jRedxw7XvU4TnMwLGn/gGU/iDO+gjGG4U6rd4xfkJbo=; b=IXyhBKHr1mkK C7JtijMohjhH0iBIjdTcB7PLNLIHVKfxmvQ0hFJxVLrC4VCXldkYqba4Sjz6Hh9B5Vv+eioWfgsYs yzzmG6cr5ybx6bdB80zXt/Ar/bW2GLnh3SuuWnripo+HE7m9nkyUiDEUPG1RsjcsvrbNaC4V14+aq ih/iUfgcz8Z9g7o59smkJUFBO8n/zPQyHLL2eAaW+vIi+OkY6JPN/XuWoZ1/bT1BS/MxlcvPBdz7R TGPS2MrgFcYpunT7Tk+XBJOUUG20Lgka1ikyBwo8BXt0oapdqIF3POCZFu7fB3/dqMm5pgkGJ/F2V 1DmAgmnhWZ9cnIpf95Ps4A==; Original-Received: from [87.69.77.57] (port=1852 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojEWz-0008Ho-L3; Fri, 14 Oct 2022 02:50:53 -0400 In-Reply-To: <87ilknidkv.fsf@posteo.net> (message from Philip Kaludercic on Thu, 13 Oct 2022 22:05:52 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:245373 Archived-At: > From: Philip Kaludercic > Cc: juri@linkov.net, rpluim@gmail.com, 57400@debbugs.gnu.org, ane@iki.fi > Date: Thu, 13 Oct 2022 22:05:52 +0000 > > > Also, there's a passive tense here... > > (This is getting embarrassing...) No need, it takes time to develop sensitivity to this stuff, and all of us, including myself, make these mistakes from time to time. > I've rewritten the entire thing, how does this sound: > > "Translate COMMIT string into symbolic form. > A symbolic form is any revision that is not expressed in using > SHA-1 object name. If the optional argument FORCE is non-nil, > this might include revision specifications like \"master~8\" (the > 8th parent of the commit that \"master\" is currently pointing > to). If it is not possible to determine a symbolic commit, the > function returns nil." This is much better, but still leaves some obvious questions unanswered. > Translate COMMIT string into symbolic form. What is a "COMMIT string"? I guess you mean the commit ID, and the "string" part is just to indicate that its Lisp data type is a string? If so, we usually say something like Translate Git revision descriptor of COMMIT, a string, to a symbolic form. > If the optional argument FORCE is non-nil, > this might include revision specifications like \"master~8\" (the > 8th parent of the commit that \"master\" is currently pointing > to). This begs the question: what kind of COMMIT strings are acceptable if FORCE is nil or omitted? If we only accept SHA-1 hashes then, this should perhaps be mentioned in the first sentence. But from reading the (unhelpful) man page of "git name-rev" (which leads down the rabbit hole to "git rev-parse"), it is my understanding that this will accept _any_ revision descriptor in any form. So now I wonder why accepting something like "master~8" needs a special knob: it's just one of the forms supported by "git name-rev", isn't it? So maybe you don't even need the additional argument and don't have to document it? But if there _are_ valid reasons not to accept the likes of "master~8", they should be in the doc string. For example: By default, COMMIT strings of the form "master~8" are rejected, because , but if FORCE is non-nil, they are allowed. If "master~8" (or in general SOMETHING~N) is not the only form that is rejected, the description should include the other forms as well, perhaps as examples. (And note that the text I proposed above fixed yet another inconsistency: COMMIT is first described as a "revision" and "string" and then as "revision specification"; a good doc string should use the same consistent terminology throughout.) > If it is not possible to determine a symbolic commit, the > function returns nil. Again, for consistency, it is better to say If it is not possible to determine the symbolic form of COMMIT, the function returns nil. because the first sentence talked about converting COMMIT into a symbolic form. Thanks, and keep up the good work.