Why not rebase instead of merge?

[Andy Adams-Moran]

Can the standard workflow be scripted?

On Sun, Feb 24, 2013 at 2:43 AM, Alexander Kjeldaas
<alexander.kjeldaas at gmail.com> wrote:
> 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
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>