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 <[email protected]> wrote: > 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 > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
