From: Dmitry Gutov <dgutov@yandex.ru>
To: Uwe Brauer <oub@mat.ucm.es>
Cc: emacs-devel@gnu.org
Subject: Re: [patch: first impression]
Date: Tue, 11 Oct 2022 05:05:02 +0300 [thread overview]
Message-ID: <43e67d5a-e3f4-3e7d-cd0e-819a08279d7e@yandex.ru> (raw)
In-Reply-To: <87fsfv1yau.fsf@mat.ucm.es>
[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]
On 10.10.2022 18:41, Uwe Brauer wrote:
>>>> "DG" == Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> On 10.10.2022 17:53, Uwe Brauer wrote:
>>>> On 10.10.2022 09:39, Uwe Brauer wrote:
>>>> Just 'git apply' on top of the latest master.
>>> I have to wait till the BUG I reported is resolved, since otherwise
>>> working with Emacs is an ordeal. However I have given it a try and
>>> it seems, that in mercurial speech,
>>> there is a
>>> hg up tip
>>> Missing, the @ is not on tip (I think called HEAD in git), but on
>>> the changeset (commit) just before.
>>> I have to debug this in order to see what is going on.
>>> The behavior is a bit annoying especially if you continue working
>>> and want to commit again, in which case you might create a new head
>>> (in mercurial speech), if you are not carefully checking the graph
>>> before.
>>> But if you do, your solution is somehow working.
>
>> OK. What if our solution also automatically calls `hg up tip` at the
>> end? Should that always work, or would it mess up situations where the
>> user actually wanted to be in that state (head not at tip), and was in
>> that originally?
>
> Let me think a bit about it and maybe ask other mercurial users on the
> hg mailing list. I would say hg up tip should be ok, since this the
> default behavior anyway
Another option is to use shelving.
See the attached slightly different patch.
>> E.g. if they wanted to "create a new head" using the new method to
>> commit a patch?
>
> I am not sure you know but in mercurial you could create an anonymous
> head (which is impossible in git, well at least not permanently) but it
> is also strongly avised against doing it, so if you want to do that you
> would create before the commit a named branch, topic or maybe a
> bookmark.
It's probably the same as "detached HEAD" in Git.
[-- Attachment #2: vc-hg-checkin-patch-with-shelve.diff --]
[-- Type: text/x-patch, Size: 2170 bytes --]
diff --git a/lisp/vc/vc-hg.el b/lisp/vc/vc-hg.el
index f4a44df3c2..30c1453e42 100644
--- a/lisp/vc/vc-hg.el
+++ b/lisp/vc/vc-hg.el
@@ -1185,19 +1185,38 @@ vc-hg-log-edit-mode
"Major mode for editing Hg log messages.
It is based on `log-edit-mode', and has Hg-specific extensions.")
+(defvar vc-hg-patch-string nil)
+
(defun vc-hg-checkin (files comment &optional _rev)
"Hg-specific version of `vc-backend-checkin'.
REV is ignored."
- (let ((amend-extract-fn
- (lambda (value)
- (when (equal value "yes")
- (list "--amend")))))
- (apply #'vc-hg-command nil 0 files
- (nconc (list "commit" "-m")
- (log-edit-extract-headers `(("Author" . "--user")
- ("Date" . "--date")
- ("Amend" . ,amend-extract-fn))
- comment)))))
+ (apply #'vc-hg-command nil 0 files
+ (nconc (list "commit"
+ "-m")
+ (vc-hg--extract-headers comment))))
+
+(defun vc-hg-checkin-patch (patch-string comment)
+ (let ((patch-file (make-temp-file "hg-patch"))
+ (shelf-name (make-temp-name "vc-checkin-patch")))
+ (with-temp-file patch-file
+ (insert patch-string))
+ (vc-hg-command nil t nil "shelve" "-d" shelf-name)
+ (vc-hg-command nil 0 nil "shelve" "-n" shelf-name)
+ (unwind-protect
+ (apply #'vc-hg-command nil 0 nil
+ (nconc (list "import" patch-file "-m")
+ (vc-hg--extract-headers comment)))
+ (progn
+ (vc-hg-command nil 0 nil "unshelve" "-n" shelf-name)
+ (delete-file patch-file)))))
+
+(defun vc-hg--extract-headers (comment)
+ (log-edit-extract-headers `(("Author" . "--user")
+ ("Date" . "--date")
+ ("Amend" . (lambda (value)
+ (when (equal value "yes")
+ (list "--amend")))))
+ comment))
(defun vc-hg-find-revision (file rev buffer)
(let ((coding-system-for-read 'binary)
next prev parent reply other threads:[~2022-10-11 2:05 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-11 8:06 log-edit-insert-changelog even when run git/hg from the Uwe Brauer
2022-09-30 0:58 ` Dmitry Gutov
2022-09-30 6:10 ` Uwe Brauer
2022-09-30 10:14 ` Dmitry Gutov
2022-09-30 15:48 ` Uwe Brauer
2022-10-01 0:10 ` Dmitry Gutov
2022-10-01 5:58 ` Uwe Brauer
2022-10-01 11:03 ` Dmitry Gutov
2022-10-01 12:51 ` Uwe Brauer
2022-10-01 18:13 ` Dmitry Gutov
2022-10-02 6:22 ` Uwe Brauer
2022-10-06 22:28 ` Dmitry Gutov
2022-10-07 6:24 ` Uwe Brauer
2022-10-10 2:10 ` Dmitry Gutov
2022-10-10 6:39 ` Uwe Brauer
2022-10-10 9:53 ` Dmitry Gutov
2022-10-10 12:41 ` [Serious BUG in master 93136169cba] (was: log-edit-insert-changelog even when run git/hg from the) Uwe Brauer
2022-10-10 13:22 ` [Serious BUG in master 93136169cba] Uwe Brauer
2022-10-10 13:23 ` [Confirmed] (was: [Serious BUG in master 93136169cba]) Uwe Brauer
2022-10-10 14:53 ` [patch: first impression] (was: log-edit-insert-changelog even when run git/hg from the) Uwe Brauer
2022-10-10 15:31 ` Dmitry Gutov
2022-10-10 15:41 ` [patch: first impression] Uwe Brauer
2022-10-11 2:05 ` Dmitry Gutov [this message]
2022-10-11 6:25 ` Uwe Brauer
2022-10-11 12:17 ` Dmitry Gutov
2022-10-11 12:24 ` Uwe Brauer
2022-10-11 16:50 ` Dmitry Gutov
2022-10-11 16:55 ` Uwe Brauer
2022-10-17 0:14 ` Dmitry Gutov
2022-10-17 5:48 ` Dr. Arne Babenhauserheide
2022-10-17 10:02 ` Dmitry Gutov
2022-10-17 7:11 ` Uwe Brauer
2022-10-17 10:04 ` Dmitry Gutov
2022-10-17 16:53 ` Uwe Brauer
2022-10-17 20:44 ` Uwe Brauer
2022-10-17 23:36 ` Dmitry Gutov
2022-10-18 6:33 ` Uwe Brauer
2022-10-18 12:23 ` Uwe Brauer
2022-10-18 12:45 ` Dmitry Gutov
2022-10-18 12:30 ` Dmitry Gutov
2022-10-18 13:28 ` Uwe Brauer
2022-10-18 14:47 ` Dmitry Gutov
2022-10-18 15:38 ` Uwe Brauer
2022-10-18 15:50 ` Dmitry Gutov
2022-10-18 16:47 ` Uwe Brauer
2022-10-18 17:30 ` Dmitry Gutov
2022-10-18 19:17 ` Dr. Arne Babenhauserheide
2022-10-18 19:29 ` Dr. Arne Babenhauserheide
2022-10-24 0:52 ` Dmitry Gutov
2022-10-24 15:34 ` Uwe Brauer
2022-10-24 16:33 ` Dmitry Gutov
2022-10-24 17:53 ` Uwe Brauer
2022-10-25 21:11 ` Dmitry Gutov
2022-10-19 5:40 ` Uwe Brauer
2022-10-24 1:03 ` Dmitry Gutov
2022-10-24 15:32 ` Uwe Brauer
2022-10-24 17:28 ` Dmitry Gutov
2022-10-25 8:19 ` Robert Pluim
2022-10-25 9:14 ` Uwe Brauer
2022-10-25 9:55 ` Robert Pluim
2022-10-25 11:15 ` Eli Zaretskii
2022-10-25 12:13 ` Uwe Brauer
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43e67d5a-e3f4-3e7d-cd0e-819a08279d7e@yandex.ru \
--to=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=oub@mat.ucm.es \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).