From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#57400: 29.0.50; Support sending patches from VC directly Date: Fri, 14 Oct 2022 21:47:43 +0000 Message-ID: <87czau6ps0.fsf@posteo.net> References: <84v8qgn1z9.fsf@iki.fi> <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> <83sfjq99vl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="756"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rpluim@gmail.com, 57400@debbugs.gnu.org, ane@iki.fi, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 14 23:48:16 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 1ojSXO-000AY2-VM for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Oct 2022 23:48:15 +0200 Original-Received: from localhost ([::1]:44476 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojSXN-00053L-La for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Oct 2022 17:48:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43286) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojSXC-000536-IV for bug-gnu-emacs@gnu.org; Fri, 14 Oct 2022 17:48:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39781) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ojSXC-0001TF-Ag for bug-gnu-emacs@gnu.org; Fri, 14 Oct 2022 17:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ojSXC-0000uF-6R for bug-gnu-emacs@gnu.org; Fri, 14 Oct 2022 17:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Oct 2022 21:48: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.16657840753452 (code B ref 57400); Fri, 14 Oct 2022 21:48:02 +0000 Original-Received: (at 57400) by debbugs.gnu.org; 14 Oct 2022 21:47:55 +0000 Original-Received: from localhost ([127.0.0.1]:38859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojSX5-0000ta-7V for submit@debbugs.gnu.org; Fri, 14 Oct 2022 17:47:55 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:45197) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojSX3-0000sk-BL for 57400@debbugs.gnu.org; Fri, 14 Oct 2022 17:47:54 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A104F240103 for <57400@debbugs.gnu.org>; Fri, 14 Oct 2022 23:47:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1665784067; bh=0eZh/HT9dXKVGCvo6mEGT/9wq2gb8YXfR/dljeqBPQA=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=rRndbuqMPgHqeFRkOLwoT5wRLwUEeA1Ftd0o2eA0+pDHXzgY9dr74vQhKkNVEjxcX 2gTuk2AkMJduXPD/wLnuUG0H+ACmN0iNDgq3dGqinHk9Sa+/qOYj4A1yBWKt7/RaWZ DdqtHYmKMFxPigNNXpeLsytZ2S8mZLqJxOfowcEJuZ4Eo2z8aeOoLQWkt+ihw4JDqE hdvoUAR1Zwxd5dowhWNtD3ZyopBCXVrEurnXQOoJXp+/WHZvMnWDnTw2iolnO+p/xq hYK/sHmeTtHhBnpDRPMG2A6FT/FlBRhtUbIuxbbylvvaF3YjdGi9e48urjuyopBqzx mdzCQVBZS9F8g== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Mq0Nw19qwz6tnC; Fri, 14 Oct 2022 23:47:44 +0200 (CEST) In-Reply-To: <83sfjq99vl.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Oct 2022 09:50:38 +0300") Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB 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:245492 Archived-At: Eli Zaretskii writes: >> 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 appreciate hearing this. >> 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. Is this perhaps not too long? Would "Translate revision string COMMIT to a symbolic form." be sufficient, especially as this is actually just an internal function that wasn't marked as such (the Git history indicates that this function, with this documentation string has been around since the initial revision of the file in 2007)? >> 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. Yes, right. And in absence of any restriction "COMMIT" should be understood to be a SHA-1 reference or a symbolic reference, right? > 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? That is an open debate, the function is currently only used in vc-git.el and is never invoked with the optional argument. I've only added it because it might be that it could be useful at some point in the future. > 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. I guess it is difficult to come up with a "valid reason", the motivation is that I wanted to have some way to ensure that `vc-git-working-revision' only returns a symbolic form iff a branch or tag is pointing to the working revision. If you think it is preferable, I could also invert the argument and make it into something like "no-relative" or even pull the check into `vc-git-working-revision'. > 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.) Good point. >> 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. Done. > Thanks, and keep up the good work. Thank you for your effort and detail.