Sean Whitton writes ("Re: Issues with using git debrebase for linux"):
> Unfortunately, I do not know precisely what conditions are required such
> that git-rebase is able to strip both commits and reversions of those
> commits. Presumably your script is not meeting those conditions.
I don't think git-rebase ever does that. I think you are just
confused.
What git-rebase is sometimes able to do is drop a patch when a series
is rebased onto a baseline which already contains an equivalant
patch. This is simply an effect of the merge algorithm and is subject
to all of the merge algorithm's failings. I try to avoid relying on
this behaviour. IME it is very capable of producing mismerges.
In the case of a rebase, that can include throwing away half of a
rebased commit and mangling the other half.
Ben: as I said earlier, I think you just need a new version of your
strip-a-patch script. It would run something like this:
export MY_STRIP_A_PATCH_RUNNING_AS_EDITOR=1
export EDITOR=my-strip-a-patch-script
unset VISUAL
git-debrebase -i
git-debrebase would invoke git-rebase which would reinvoke your
script, thinking it's the editor. Your script gets the git-rebase
todo list. Your script just has to find the git-rebase todo list item
corresponding to the commit to be replaced (`pick <old commitid>'),
and change it to say `pick <commitid for new version of patch>'
or maybe `exec git-am <some file>'.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
