>>> "DG" == Dmitry Gutov writes: > On 18.10.2022 09:33, Uwe Brauer wrote: >> - do the same but run commit-patch-buffer using the perl script >> commit-patch >> time: 26 sec > That's all after pressing C-c C-c after typing in the commit message, right? Right! > That's a lot. I have a big checkout of the Mozilla repo, and a similar > operation takes about ~3 seconds. And that already feels sluggish. Well 1. it is a huge repository, 2. It has over 200 000 commits 3. It is converted. So I did the same on the hg repository itself. Which 1. Only 200 MB 2. 50 000 commits 3. It is native hg 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. > 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? > 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 git reset --hard would be hg revert --no-backup I think -- I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine.