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: Sat, 15 Oct 2022 09:57:40 +0300 Message-ID: <83o7ud7evv.fsf@gnu.org> 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> <87czau6ps0.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5140"; 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 Sat Oct 15 08:59:14 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 1ojb8c-00019S-3A for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 Oct 2022 08:59:14 +0200 Original-Received: from localhost ([::1]:46798 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojb8a-0002QT-Oo for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 Oct 2022 02:59:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59980) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojb8Q-0002QH-Lw for bug-gnu-emacs@gnu.org; Sat, 15 Oct 2022 02:59:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40220) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ojb8Q-0005bT-Do for bug-gnu-emacs@gnu.org; Sat, 15 Oct 2022 02:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ojb8Q-0001LD-4j for bug-gnu-emacs@gnu.org; Sat, 15 Oct 2022 02:59: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: Sat, 15 Oct 2022 06:59: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.16658170855063 (code B ref 57400); Sat, 15 Oct 2022 06:59:02 +0000 Original-Received: (at 57400) by debbugs.gnu.org; 15 Oct 2022 06:58:05 +0000 Original-Received: from localhost ([127.0.0.1]:39298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojb7U-0001Ja-NF for submit@debbugs.gnu.org; Sat, 15 Oct 2022 02:58:05 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojb7S-0001J5-QU for 57400@debbugs.gnu.org; Sat, 15 Oct 2022 02:58:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39444) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojb7K-0005YC-Ub; Sat, 15 Oct 2022 02:57: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=dwLPHL3TNEQik+LMii6pDGYf3oeeLzLdSGpcReJcQYk=; b=hPOBFynixTn/ T+bPGri5fejucO0RNbDd+40P3pBkiRvGK/FExdIqC2J++VVbztsv729eVbyL983+0N3piMasXq1Dy Hdr7bI26PCOiwK0cmtX1rV9kLhqBPPJLviYFW9FUflrtIQ0VoaRycyWSUb4AjBf8ODMXzYmzlIXWh UcCxs+N7K3xr5uyEreLGGC/KNZhzDr21qcjf7oNVOLibFK2IhvaZBHnTVR0I+LGJp5xWGb8Cw0ra9 DSO0XNS7iN+rm+SpZYgZBOF1CwLoPpnn0m+NYUZCXbO4WDyrHSA0oc/c9F6thZ//HSUVmDNnUd4YE XCj79z5HCU4Vat6wz59q2Q==; Original-Received: from [87.69.77.57] (port=3146 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 1ojb7H-0006zH-Ib; Sat, 15 Oct 2022 02:57:54 -0400 In-Reply-To: <87czau6ps0.fsf@posteo.net> (message from Philip Kaludercic on Fri, 14 Oct 2022 21:47:43 +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:245508 Archived-At: > From: Philip Kaludercic > Cc: juri@linkov.net, rpluim@gmail.com, 57400@debbugs.gnu.org, ane@iki.fi > Date: Fri, 14 Oct 2022 21:47:43 +0000 > > > 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)? I disregarded the fact that this is an internal function, because the issues are general. But yes, we could make this shorter, once we agree that the full text should be something like I suggested. For example: Translate revision string of COMMIT to a symbolic form. Note that I said "string of COMMIT", because COMMIT is not a string, it is an entity which the string describes. > >> 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? Hmm... now I'm confused. I'd think COMMIT could be _any_ reference to a revision, not just SHA-1? Because "git name-rev" accepts them all, no? > > 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'. I'm asking why not accept everything that "git name-rev" accepts, and remove the need for the additional FORCE argument. (But this is not a documentation issue anymore ;-)