> 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 Date: Thu Apr 10 20:43:54 1997 +0000 ^^^^^^^^^^^^^^^^^^^^^^^^ Initial revision A lisp/emulation/crisp.el commit d31cf3156c20512f7fcf72b383827e96cfc9718e Author: Stefan Monnier 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...