emacs-devel
[Top][All Lists]
Advanced

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

Re: Please don't obsolete "crisp.el"


From: Stefan Monnier
Subject: Re: Please don't obsolete "crisp.el"
Date: Thu, 10 Jul 2014 09:48:30 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

>>>> ELPA with Emacs crisp.el merged >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> commit 8739586a2539b482bdb48350bbcda00c44d82805
> Author: Stefan Monnier <address@hidden>
> Date:   Mon Jul 7 09:17:28 2014 -0400

>     * caps-lock: New package.

> +commit 086a393b7aae6fbe214839aea67a02133f5ef955
> +>Author: Glenn Morris <address@hidden>
> +Date:   Sun Jul 6 16:58:52 2014 -0700
> +
> +    * cua-rect.el (cua--activate-rectangle): Avoid setting cua--rectangle
> ...

Hmm?? The above cua-rect.el commit did not touch crisp.el, so it seems
not just annoying but incorrect for it to be there.  It points to
a problem in the way crisp.el's changes are selected.

> 1. I found that in the Emacs repo git clone, A LOT OF commits did not even
>    touched crisp.el but are all included in the log history of
>    crisp.el.  I don't know if it's caused by bzr -> git mirroring
>    information loss, or if this happend even in earlier years before
>    bzr is used, or if there are some defetcts during git
>    filter-branch.  This seems to leave quite a few dummy commits
>    without any diff against crisp.el.

"bzr log -n 0 lisp/obsolete/crisp.el| grep revno | wc"

gives me 77 "commits".  Looking at the entries, they all seem to be
somewhat related to crisp.el, so it looks like a problem on Git's side.

> 2. We merged only the commits that relates to "crisp.el".  But those commits
>    might not just crisp.el specific and touched other files too.
>    You will still see the diff of other Emacs trunk files that never
>    exists in ELPA, when examine those commits in detail.

Yuck.

If the "extra spurious commits" or the "extra spurious files in commits"
are not too frequent (like 10% of the crisp.el history), it's not
too bad.  But if it's much more significant, then we're better off
without the history (which is still available in Emacs's repository
anyway).


        Stefan



reply via email to

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