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

[Luke Lee <luke.yx.lee@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]

>    git log --follow lisp/obsolete/crisp.el | grep commit | wc
>
> gives me 56 entries, which all seem to have touched crisp.el, so the
> mirroring doesn't seem to be the problem.
> ...
> Also, "git log -p --follow lisp/obsolete/crisp.el" seems to include just
> the crisp.el changes, so passing it to "git am" might DTRT.

Cool! The "git log -p --follow lisp/obsolete/crisp.el" is indeed very clean!
However, the bad thing is that we can't add "--reverse" to reverse the
commit order from the beginning, so "git am" will immediately fail. Later
I figure out the correct sequence using lisp/emulation instead:

  git log --pretty=email -p --all --follow --reverse --
lisp/emulation/crisp.el

A crisp.el only history patch generated. However, when applying it to "git
am",
it failed at the 18th historical commit, which I have no idea why.

Another bad thing about "git am" is that it will commit "on top of" current
commit so we'll see a history like the following using "git log":

---------------------------
commit 35f5a599cf5dcb6a2a79c79048d645b48dcf043a
Author: Richard M. Stallman <rms@gnu.org>
Date:   Thu Apr 10 20:43:54 1997 +0000
        ^^^^^^^^^^^^^^^^^^^^^^^^

    Initial revision

A       lisp/emulation/crisp.el

commit d31cf3156c20512f7fcf72b383827e96cfc9718e
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Mon Jul 7 14:38:27 2014 -0400

    * xpm: Fix cl-lib usage and compilation failures.

M       packages/xpm/xpm-compose.el
M       packages/xpm/xpm-ops.el
M       packages/xpm/xpm-palette.el
M       packages/xpm/xpm-ui.el
-------------------------

Gee! The history suddenly back from 2014 to 1997! I believe people won't
like this.

The filter-branch approach does not have such flaw, but it contains
some garbage info unrelated to crisp.el. However, it's not a lot, maybe
< 10% of the commits but I don't have the real number. I just randomly
checked in the history log. Seems each approach has its own pros and
cons here...

[-- Attachment #2: Type: text/html, Size: 2515 bytes --]