Why not rebase instead of merge?
alexander.kjeldaas at gmail.com
Sun Feb 24 11:43:46 CET 2013
You'd optionally want to squ
On Sun, Feb 24, 2013 at 4:15 AM, Johan Tibell <johan.tibell at gmail.com>wrote:
> On Sat, Feb 23, 2013 at 2:33 PM, Simon Peyton-Jones <simonpj at microsoft.com
> > wrote:
>> I'm ok with changing my workflow if that'd give better history. But
>> someone would need to explain the new workflow carefully on the wiki. At
>> the moment my general plan is:
>> * make some changes
>> * commit as patches
> * validate
Here you might want to do a
git rebase -i <when-you-split-from-main-branch>
and squash unnecessary commits into larger ones.
> * pull
git pull --rebase
Since rebase will generate conflicts on each commit, it's better to squash
unnecessary stuff before this pull, I think.
> * fix conflicts
>> * revalidate if the conflicts look at all suspicious
>> * push
> It ought to be the same, with pull replaced with pull --rebase. That being
> said it's late here and I haven't thought it over carefully. I suggest you
> try it on a small change first. :)
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs