Front page | perl.perl5.porters |
Postings from January 2012
On Fri, Jan 13, 2012 at 05:40:21PM +0100, Nicholas Clark wrote: > In perl.git, the branch nicholas/re-instate has been updated > > <http://perl5.git.perl.org/perl.git/commitdiff/8deb7dbdfbd6e133d6cde85839a8acacd2185e32?hp=cc5038fb0fb4077cf2d3724595ce66f81c7eb10a> > > - Log ----------------------------------------------------------------- > commit 8deb7dbdfbd6e133d6cde85839a8acacd2185e32 > Merge: 9e6704a cc5038f > Author: Nicholas Clark <nick@ccl4.org> > Date: Fri Jan 13 17:33:24 2012 +0100 > > Revert "EPOC is special biologist word. [Do not merge to blead]" > > This reverts commit 9a35cdd44afd0278caefb55a0bb28e5b14175002. But witness the blame annotation on http://perl5.git.perl.org/perl.git/blame/8deb7dbdfbd6e133d6cde85839a8acacd2185e32:/perl.h#l2591 It's back in 2001 like nothing had happened. Whereas (pretty sure) a regular revert ends up with blame as that commit. What I did was: 1: make a disposable branch from the commit before the one I was interested in 2: merge my real branch (pretend blead) into *it* (so that the current tip is the *not* the first parent) 3: git revert as usual after that 4: git reset HEAD^ 5: git add everything that should be there 6: git commit --amend on the merge commit 7: git push my disposable branch as the original name - it's a fast forward Although I have this horrid feeling that this will also "reset" the blame annotation on every other file that has diverged between the two as if it came from the merge commit. So maybe it's not a great idea. [OK, why? Because I'd like to know if it's possible to have the effect of a git revert, but merged or somesuch in such a way that blame annotation easily sees the lines of the restored files as if they were never deleted] Nicholas Clark