Re: Issues with using git debrebase for linux

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

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 <ijackson@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.