Why not rebase instead of merge?
Alexander Kjeldaas
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
>>
>
And then
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
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130224/aab29e21/attachment.htm>
More information about the ghc-devs
mailing list