Merging a branch
jwlato at gmail.com
Thu Oct 16 08:32:47 UTC 2014
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.
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
> resolving merge conflicts, rebase doesn't really know how to take
> advantage of that, so you'll have to redo it.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs