Re: [patch: first impression]

[Dmitry Gutov <dgutov@yandex.ru>]

On 18.10.2022 16:28, Uwe Brauer wrote:

> I did the same, reverted to files edit the diff and then commited
> 
>      1. Lisp implementation 8 sec
> 
>      2. Commit-patch 4 sec
> 
> 
> Not sure what is the conclusion here. Well in general hg is slower especially if there are a lot of named branches, but the emacs-hg repository has one the default
> and hg has 2, default and stable
> 
> Strange indeed.

Try this modification:

diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index df51f52bc7..3e78b8cfe9 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -1715,9 +1715,6 @@ vc-default-checkin-patch
                                               "--no-backup-if-mismatch"
                                               "-i" "-"))
                (user-error "Patch failed: %s" (buffer-string))))
-          (dolist (f files)
-            (with-current-buffer (get-file-buffer f)
-              (revert-buffer t t t)))
            (vc-call-backend backend 'checkin files comment))
        (dolist (f files)
          (copy-file (expand-file-name f tmpdir)


This step is probably unnecessary, and might take up extra time.

>> But of course it depends on the number of files and their sizes, I suppose.
> 
>>> Conclusion, for most practical purpose the lisp implementation is
>>> enough. I just considered an extreme case.
> 
>> Wish we managed to implement something faster for Hg.
> 
>> 'hg import --bypass' seemed the most promising option, but the 'hg
>> update tip' step that you suggested can end up in conflict.
> 
> 
> It is not clear to me why?

The patch you might be committing can have changes conflicting with the 
existing modifications inside the same files. We decided to allow that 
(because diff-mode definitely permits such modification).

But 'hg update', when the file has certain changes in the same area that 
should be updated with the switch between revisions, drops you into 
merge mode.

>> I've searched for some "plumbing" Hg command corresponding to 'git
>> reset --soft' and couldn't find it.
> 
>   git reset --soft
>   should be
> 
>    hg revert
> 
> if I am not mistaken

No, 'hg revert' is the same as 'git checkout FILE' or 'git restore 
FILE'. It affects the file contents.

Whereas 'git reset --soft' only switches the current HEAD to a different 
revision, without touching the file contents on disk (those outside of 
.git directory, of course).