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 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 ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Hello, Simon, I wouldn't worry about my branch---my changes are fairly orthogonal, so it shouldn't be too hard for me to the same sort of operation on top of `master`, once your changes are in there. -Iavor On Thu, Oct 16, 2014 at 2:24 AM, Joachim Breitner wrote:

Hi,

Am Donnerstag, den 16.10.2014, 08:08 +0000 schrieb Simon Peyton Jones:

...

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.

Not too crude, if your new set of (logically interesting) patches is going to be completely different from your original set of (historically grown) patches.

Here is one workflow for that: (aren’t you glad that you get so many different suggestions :-)

$ git checkout master

# We first create a branch that contains the final state of the files # that you will like to push $ git checkout -b tmp-merge-branch $ git merge wip/new-flatten-skolems-Aug14 # resolve your conflicts here, once

# now you have a branch with your desired final state, but a messy # history. We now create multiple nice patches from that state that, # together, yield the same result: $ git checkout master $ git checkout --patch tmp-merge-branch # now you can interactively select portions from your patch. Select # those that you want in your first polished commit $ emacs .... # do any additional cleanup of this commit, if required $ git commit -a -m 'First patch' $ git checkout --checkout tmp-merge-branch # Select parts for the second commit $ emacs .... # do any additional cleanup of this commit, if required $ git commit -a -m 'Second patch' ... repeat ... # (in the final "git checkout --patch", you should have selected all # changes)

# now master is identical to tmp-merge-branch, check this using $ git diff master..tmp-merge-branch $ git branch -D tmp-merge-branch $ git push origin master

Greetings, Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs