Merging a branch

[John Lato]

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 <ezyang at mit.edu> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141016/9227355a/attachment.html>