emacs-devel
[Top][All Lists]
Advanced

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

Re: [patch: first impression]


From: Uwe Brauer
Subject: Re: [patch: first impression]
Date: Tue, 18 Oct 2022 14:23:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

>>> "UB" == Uwe Brauer <oub@mat.ucm.es> writes:

>> On 17.10.2022 23:44, Uwe Brauer wrote:

>> Thanks for testing, please try again with the latest master, I pushed
>> a fix in 5e77265523.

>> Or maybe try with 7bf17ceee8c2d, with patches 4a6ad6e18f and
>> 5e77265523 on top of it.

> Thanks, your latest commit  works with commit 7bf17ceee8c2d.

> Some benchmarks.

> I cloned emacs master with hg 

> |     | repo size (GB) |
> | Git |            1.4 |
> | HG  |            1.8 |

> I am using for this experiment master 0954689cb

> Steps:

>     - hg src/xfns.c    -r b9aff5fdb89092b68 (git reset (not sure hard or soft)

>     - hg src/xterm.c    -r b9aff5fdb89092b68

>     - vc-dir (mark the two files)

>     - vc-diff

>     - delete hunks

>     - run vc-next-action: time: 36 sec on my X1 Thinkpad 2017

>     - do the same but run commit-patch-buffer using the perl script
>       commit-patch
>       time: 26 sec 

> Conclusion, for most practical purpose the lisp implementation is
> enough. I just considered an extreme case.

I just realised that after finishing, the repository contains the files 
 
xterm.c.orig
xfns.c.orig

I can easily get rid of them by running 

 hg purge (or git clean -fd)

But what is the purpose of leaving these files, is this by design or a
side effect of your implementation.


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

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

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