emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch: first impression]


From: Dmitry Gutov
Subject: Re: [patch: first impression]
Date: Tue, 18 Oct 2022 17:47:25 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2

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).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]