On Wed, Jul 13, 2016 at 1:47 PM, Sven Axelsson wrote: >> Yes, this is a common need and Git should be changed to allow editing >> of commit log entries even though this could be said to change the >> state of the prior releases. > > > A couple of months ago it was suggested to use `git replace --edit` for > that. > Did anyone try it out to see if it could be used in the Emacs workflow? There were some questions raised, the 2 main ones were 1. How to deal with the fact git replace is powerful enough to replace the actual content of the commit. This is easy enough to stop with a hook, see attached pre-receive. 2. Performance implications of having many replacements. This appears to be a more serious problem. The git replace command creates a ref per replacement. Since we expect our number of replacements to be some fraction of the commits, we could end up with quite a few. To get a sense of the worst case timing I wrote a script to replace the message of every commit in the repository with an upcased SHOUTY version. After running it on an Emacs repo clone, my .git/refs/replace directory was 8.5M in size. I tried git pack-refs --all which emptied the the replace directory, and resulted in a 12M packed-refs file. Doing git log became dramatically slower (packing the refs did not make much difference). Original repository: ~/src/emacs/emacs-master$ time git log --oneline | wc -l 126614 real 0m5.435s user 0m3.157s sys 0m2.780s ~/src/emacs/emacs-master$ time git log --oneline | head >/dev/null real 0m0.009s user 0m0.003s sys 0m0.003s Repository with all commit messages replaced: (almost all, there were a few messages that lacked letters, so my upcasing script had no effect) ~/src/emacs/emacs-clone$ time git log --oneline | wc -l 126614 real 0m49.337s user 0m8.270s sys 0m39.680s ~/src/emacs/emacs-clone$ time git log --oneline | head >/dev/null real 0m0.520s user 0m0.237s sys 0m0.250s I attached the scripts used (upcase-commit-message.sh and git-replace-all.sh), in case anyone wants to replicate my experiments.