* Rene Herman <rene.herman@xxxxxxxxxxxx> wrote:
Thanks and fine ofcourse but from the Cheats 'R Us GIT handbook, when there's n patches on top of the one I want to edit:
$ mkdir tmp
$ git format-patch -o tmp HEAD~n
$ git reset --hard HEAD~n
$ git reset --soft HEAD^
<fix>
$ git commit -a -c ORIG_HEAD
$ git am tmp/*
$ rm -rf tmp
Just in case someone finds it interesting... :-)
i think something like this would do it as well:
git-rebase -i HEAD~$[n+1]
Change the patch you want to edit from 'pick' to 'edit', and do a "git commit --amend" to fix it up and then a "git rebase continue" to reapply the other n patches ontop of the changed patch. (This is straight from the Cheats 'R Us GIT handbook, second edition ;-)
The problem with rebasing though is that it does not interact with normal Git workflows very nicely. Someone might have based further work on those sha1's that we now change under them. When that further work is backmerged later on we have overlapping sha1's.
There are two further specific non-Git-workflow arguments in favor of the delta patch as well:
- in this case your first change was the obvious one and your NULL fix and your cleanup to the parameter expose a fundamental weakness of
early_param conversions - and i think highlighting that as separate commits might give someone ideas to improve the early_param() facility, if they see the fix patterns.
- Also, the NULL condition is obscure, so there's no bisection breakage
risk and it's the easiest for me to do append-only patches. The effort
and thought process you and Cyrill have put into it deserve a separate
commit as well anyway - and others might learn from it when looking at
logs.