I think it's often useful to use git rebase -i for an interactive rebase,
sometimes I even run it multiple times in succession. I usually start by
squashing any adjacent commits that should be logically grouped together
(one pass), then re-ordering and squashing again. This isolates any
complicated edits that I had to perform in order to re-order patches.
As Edward points out you'll have to redo edits of merge conflicts, unless
you've enabled rerere: http://git-scm.com/blog/2010/03/08/rerere.html. You
probably want to enable it.
John L.
On Thu, Oct 16, 2014 at 1:15 AM, Edward Z. Yang
You might try and run 'git rebase' (you can run 'git rebase --abort' if things get too hairy), which will remove the merge patches and put your patchset on HEAD. Unfortunately, if you've done nontrivial work resolving merge conflicts, rebase doesn't really know how to take advantage of that, so you'll have to redo it.
Edward
Excerpts from Simon Peyton Jones's message of 2014-10-16 01:08:15 -0700:
Friends
I have a branch, wip/new-flatten-skolems-Aug14, which has a long succession of work-in progress patches. Plus a couple of merges from HEAD.
I'd like to completely re-organise the patches before committing to HEAD. How do I do that? Some kind of rebase? Clearly I want to start from current HEAD, rather than having weird merge patches involved.
I was thinking of starting a new branch and doing a manual diff/patch, but that seems crude.
I think that one other person (Iavor) has pulled from this branch, but he has not modified it.
Thanks
Simon
ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs