From: Philip Kaludercic <philipk@posteo.net>
To: Juri Linkov <juri@linkov.net>
Cc: Robert Pluim <rpluim@gmail.com>,
57400@debbugs.gnu.org, Antoine Kalmbach <ane@iki.fi>
Subject: bug#57400: 29.0.50; Support sending patches from VC directly
Date: Tue, 11 Oct 2022 19:30:50 +0000 [thread overview]
Message-ID: <87edvecg45.fsf@posteo.net> (raw)
In-Reply-To: <86sfjvqz68.fsf@mail.linkov.net> (Juri Linkov's message of "Mon, 10 Oct 2022 22:03:11 +0300")
[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]
Juri Linkov <juri@linkov.net> writes:
>> Again, regarding `crm-separator' I don't know if this is a value that
>> people change or not (perhaps it should be changed to a defconst).
>
> At least, it's not defcustom, so it's not intended for user customization.
>
>> I can also imagine that the initial input outside of a log buffer ought
>> to just be the last commit.
>
> Depends on whether this is one of the most popular workflows.
>
>>> Additional question: shouldn't the behavior of
>>> vc-prepare-patches-separately=nil be equivalent to
>>> vc-prepare-patches-separately=t when only one revision is given? Both
>>> cases create just one mail. So when vc-prepare-patches-separately is
>>> nil, could it extract the subject from the single revision? Or maybe
>>> vc-prepare-patches-separately should support a new customization value
>>> for this?
>>
>> Yes, but the formatting is different. In the one case you attach a
>> patch to a regular message, while in the other case the message is
>> prepared in such a way that (at least when using Git) the entire message
>> is a valid patch, where we can use "git am".
>
> Hmm, I tried both variants, and still not sure which is better
> for the 1-patch case. However, what I definitely suggest to do is
> to get rid of recursive-edit, that also Robert noticed on emacs-devel.
> recursive-edit is too fragile for modal editing, because such
> commands as keyboard-escape-quit can easily break it. Without
> recursive-edit you can just create all mail buffers at once.
> Then after sending one mail, its buffer gets buried, and the
> next mail buffer will be shown instead, etc.
I have done all of the above and am prepared to push the changes, but
before I do I was wondering if anyone would have any objections to the
following changes to vc-git.el:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-vc-vc-git.el-vc-git-rev-parse-Abbreviate-commit.patch --]
[-- Type: text/x-patch, Size: 1005 bytes --]
From 7d3a07bc6fdfae579681d8e71685d94b7bfa9ad3 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 11 Oct 2022 21:11:20 +0200
Subject: [PATCH 1/2] * lisp/vc/vc-git.el (vc-git--rev-parse): Abbreviate
commits
---
lisp/vc/vc-git.el | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
index ea06ccaf87..3822bb8574 100644
--- a/lisp/vc/vc-git.el
+++ b/lisp/vc/vc-git.el
@@ -1677,8 +1677,10 @@ vc-git-previous-revision
(defun vc-git--rev-parse (rev)
(with-temp-buffer
(and
- (vc-git--out-ok "rev-parse" rev)
- (buffer-substring-no-properties (point-min) (+ (point-min) 40)))))
+ (vc-git--out-ok "rev-parse" "--short" rev)
+ (string-trim-right
+ (buffer-substring-no-properties (point-min) (min (+ (point-min) 40)
+ (point-max)))))))
(defun vc-git-next-revision (file rev)
"Git-specific version of `vc-next-revision'."
--
2.37.3
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Return-symbolic-commit-for-the-working-revision-if-p.patch --]
[-- Type: text/x-patch, Size: 937 bytes --]
From 8bb9fbfdb39d1fd17430f24e9572bf4dde830758 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 11 Oct 2022 21:14:48 +0200
Subject: [PATCH 2/2] Return symbolic commit for the working revision if
possible
* lisp/vc/vc-git.el (vc-git-working-revision): Attempt to use
'vc-git-symbolic-commit'.
---
lisp/vc/vc-git.el | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
index 3822bb8574..d17c02852c 100644
--- a/lisp/vc/vc-git.el
+++ b/lisp/vc/vc-git.el
@@ -373,8 +373,9 @@ vc-git-state
(defun vc-git-working-revision (_file)
"Git-specific version of `vc-working-revision'."
- (let (process-file-side-effects)
- (vc-git--rev-parse "HEAD")))
+ (let* ((process-file-side-effects nil)
+ (commit (vc-git--rev-parse "HEAD")))
+ (or (vc-git-symbolic-commit commit) commit)))
(defun vc-git--symbolic-ref (file)
(or
--
2.37.3
next prev parent reply other threads:[~2022-10-11 19:30 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-25 8:47 bug#57400: 29.0.50; Support sending patches from VC directly Antoine Kalmbach
2022-08-26 7:37 ` Philip Kaludercic
2022-08-26 10:15 ` Antoine Kalmbach
2022-08-26 10:35 ` Philip Kaludercic
2022-08-26 10:45 ` Antoine Kalmbach
2022-08-26 10:58 ` Eli Zaretskii
2022-08-26 11:26 ` Philip Kaludercic
2022-08-26 11:44 ` Eli Zaretskii
2022-08-26 12:05 ` Philip Kaludercic
2022-08-26 12:26 ` Eli Zaretskii
2022-08-26 13:10 ` Antoine Kalmbach
2022-08-26 13:17 ` Eli Zaretskii
2022-08-26 13:29 ` Philip Kaludercic
2022-08-26 14:21 ` Eli Zaretskii
2022-08-27 8:21 ` Philip Kaludercic
2022-08-27 9:21 ` Eli Zaretskii
2022-08-27 9:30 ` Philip Kaludercic
2022-08-26 12:08 ` Antoine Kalmbach
2022-08-26 12:28 ` Eli Zaretskii
2022-08-28 4:07 ` Richard Stallman
2022-10-03 18:59 ` Philip Kaludercic
2022-10-03 19:06 ` Lars Ingebrigtsen
2022-10-03 19:23 ` Eli Zaretskii
2022-10-04 19:19 ` Philip Kaludercic
2022-10-04 19:33 ` Eli Zaretskii
2022-10-03 21:22 ` Philip Kaludercic
2022-10-03 21:55 ` Philip Kaludercic
2022-10-03 23:32 ` Lars Ingebrigtsen
2022-10-04 6:46 ` Eli Zaretskii
2022-10-04 6:41 ` Eli Zaretskii
2022-10-04 7:10 ` Philip Kaludercic
2022-10-04 8:00 ` Eli Zaretskii
2022-10-04 10:40 ` Philip Kaludercic
2022-10-04 10:42 ` Philip Kaludercic
2022-10-04 12:25 ` Eli Zaretskii
2022-10-04 12:24 ` Eli Zaretskii
2022-10-04 18:08 ` Philip Kaludercic
2022-10-05 16:07 ` Antoine Kalmbach
2022-10-05 17:34 ` Philip Kaludercic
2022-10-05 17:48 ` Philip Kaludercic
2022-10-05 18:32 ` Lars Ingebrigtsen
2022-10-05 18:46 ` Philip Kaludercic
2022-10-05 19:08 ` Lars Ingebrigtsen
2022-10-06 8:21 ` Robert Pluim
2022-10-06 8:35 ` Philip Kaludercic
2022-10-06 8:59 ` Robert Pluim
2022-10-06 9:12 ` Philip Kaludercic
2022-10-06 11:02 ` Philip Kaludercic
2022-10-05 19:57 ` Juri Linkov
2022-10-06 12:03 ` Lars Ingebrigtsen
2022-10-07 22:48 ` Richard Stallman
2022-10-10 14:39 ` Filipp Gunbin
2022-10-10 18:58 ` Juri Linkov
2022-10-11 0:27 ` Lars Ingebrigtsen
2022-10-11 0:26 ` Lars Ingebrigtsen
2022-10-05 18:17 ` Eli Zaretskii
2022-10-05 18:45 ` Philip Kaludercic
2022-10-06 9:14 ` Philip Kaludercic
2022-10-06 9:19 ` Eli Zaretskii
2022-10-06 22:22 ` Dmitry Gutov
2022-10-07 6:36 ` Eli Zaretskii
2022-10-07 12:06 ` Dmitry Gutov
2022-10-06 11:33 ` Robert Pluim
2022-10-06 12:38 ` Philip Kaludercic
2022-10-06 12:58 ` Robert Pluim
2022-10-06 14:37 ` Philip Kaludercic
2022-10-06 14:43 ` Robert Pluim
2022-10-06 15:54 ` Eli Zaretskii
2022-10-06 16:27 ` Philip Kaludercic
2022-10-07 7:58 ` Juri Linkov
2022-10-07 11:42 ` Philip Kaludercic
2022-10-08 10:03 ` Philip Kaludercic
2022-10-08 19:34 ` Juri Linkov
2022-10-09 12:15 ` Philip Kaludercic
2022-10-10 19:03 ` Juri Linkov
2022-10-11 12:44 ` Philip Kaludercic
2022-10-11 13:58 ` Robert Pluim
2022-10-15 18:54 ` Juri Linkov
2022-10-16 9:40 ` Philip Kaludercic
2022-10-11 19:30 ` Philip Kaludercic [this message]
2022-10-11 19:47 ` Juri Linkov
2022-10-11 19:49 ` Philip Kaludercic
2022-10-12 22:01 ` Richard Stallman
2022-10-13 7:04 ` Juri Linkov
2022-10-13 21:12 ` Richard Stallman
2022-10-15 19:02 ` Juri Linkov
2022-10-13 8:55 ` Philip Kaludercic
2022-10-13 17:30 ` Juri Linkov
2022-10-13 19:44 ` Philip Kaludercic
2022-10-13 20:25 ` Philip Kaludercic
2022-10-13 20:33 ` Eli Zaretskii
2022-10-13 22:05 ` Philip Kaludercic
2022-10-14 6:50 ` Eli Zaretskii
2022-10-14 21:28 ` Richard Stallman
2022-10-14 21:47 ` Philip Kaludercic
2022-10-15 6:57 ` Eli Zaretskii
2022-10-15 11:44 ` Philip Kaludercic
2022-10-15 12:20 ` Eli Zaretskii
2022-10-15 15:15 ` Philip Kaludercic
2022-10-15 15:16 ` Eli Zaretskii
2022-10-15 15:24 ` Philip Kaludercic
2022-10-10 22:01 ` Richard Stallman
2022-10-11 5:37 ` Eli Zaretskii
2022-10-12 21:59 ` Richard Stallman
2022-10-06 22:10 ` Dmitry Gutov
2022-10-07 8:03 ` Philip Kaludercic
2022-10-07 12:56 ` Dmitry Gutov
2022-10-07 15:30 ` Philip Kaludercic
2022-10-07 15:47 ` Dmitry Gutov
2022-10-07 15:54 ` Philip Kaludercic
2022-10-08 22:34 ` Richard Stallman
2022-10-08 12:11 ` Philip Kaludercic
2022-10-08 12:44 ` German Pacenza
2022-10-08 13:02 ` Philip Kaludercic
2022-10-08 13:07 ` Dmitry Gutov
2022-10-08 13:42 ` Philip Kaludercic
2022-10-08 14:02 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87edvecg45.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=57400@debbugs.gnu.org \
--cc=ane@iki.fi \
--cc=juri@linkov.net \
--cc=rpluim@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.