Ptr accel API changes

[Peter Hutterer]

On Wed, Jun 24, 2009 at 02:10:00PM +0200, Simon Thum wrote:
> Julien Cristau wrote:
>> On Wed, Jun 24, 2009 at 12:38:50 +0200, Simon Thum wrote:
>>
>>> BTW, how do you edit unpushed commits which have dependent follow-ups?
>>>
>>> I use a git format-patch, reset, commit, am sequence. You know a 
>>> smarter  way, particularly one avoiding reset?
>>>
>> 'git rebase -i' might be what you're looking for.
> I use it regularly, but AFAIK it doesn't help me much if changes are  
> convoluted by the follow-ups (that's what I meant by 'dependent'  
> follow-ups, my bad).
>
> My case was: First commit changes a signature, second does param  
> renames, third declares it internal. So to change the first one I have  
> to edit off it using reset, which would kill subsequent ones. And that's  
> what I'd like to avoid. Format-patch and stash helps it, but my guts  
> tell me this could be done in a less stupid manner.

There's no automatic way to do what you need, but rebase -i does make things
a bit easier. It's harder to split a patch once merged than to squash two
patches together, so _always_ err on the side of too many commits.
This even goes for patch submission, if you give me two patches that I think
should be one it takes me less than a minute to squash them.

For the patch you submitted, the way to split it up again is:
- git reset HEAD~1 # reset index, not code
- git add -i, add all hunks that are renames only, commit
- git add -i, add all hunks that are renames + API change, commit
  i.e. those hunks that change foo(int A) into foo(int a, int b)
- edit the file, remove all API changes, but leave the names, commit
  i.e. change foo(int a, int b) into foo(int a)
- git rebase -i, swap the last two commits, resolve the conflicts, done.
- git rebase -i, sqash the first two commits

you now have two commits left - one with the renaming, one with the API
change after renaming.

The commit that changes to internal which applies on top is mostly
unaffected in your case I think. If you have a truly dependent chain of
commits that follow, create a temporary branch with the current state, then
reset master and fix it up. Then cherry-pick the follow-up commits from the
other branch on top of master, git will resolve conflicts quite well.

so given that you're on a botched master:

git checkout -b temp # temp == master now
git checkout master  # leave temp as a backup branch
git reset --hard <sha1>
.. fix master
for commit in temp (after master)
    git cherry-pick commit

You can also do the whole thing using git format-patch and git am, but both
don't allow for the use of tig (which makes cherry-picking a lot easier),
git am has bad conflict resolution and once you have a commit in the tree
and you really really screw up, you can always recover with git fsck
--lost-found.

Cheers,
  Peter