[Microbit-Python] Merging Pull requests.

[Guido van Rossum]

On Sun, Nov 22, 2015 at 3:32 PM, Mark Shannon <mark at hotpy.org> wrote:
> Hi Guido,
> I didn't know you were taking an interest in this project. Do you have a
> micro:bit?

Yes, Nick sent me one. I haven't had much time to play with it, but I
showed it off at a conference a few weeks ago to great acclaim.

> I think the advantage of the GitHub model is that it is equitable.
> Working on CPython has convinced me that a fair and democratic model is very
> important.

I'm sorry already I jumped into the discussion; I have no desire to continue it.

--Guido

> Cheers,
> Mark
>
>
> On 22/11/15 23:12, Guido van Rossum wrote:
>>
>> I believe this is a topic of holy war proportions. I agree with
>> Damien, branches are distracting in the long-term history (and so are
>> GitHub merge turds). Tooling can help here (though I don't know what
>> to recommend -- at Dropbox we use Phabricator which takes care of this
>> for us but it's too heavy for an open source project). Code review is
>> of course a different topic, I agree that all code should be reviewed
>> before it is merged/rebased.
>>
>> On Sun, Nov 22, 2015 at 3:01 PM, Damien George
>> <damien.p.george at gmail.com> wrote:
>>>
>>> Hi Mark,
>>>
>>> I always rebase a branch before merging, and this (usually) means that
>>> the git hash changes and so your "git branch -d" will need to be a
>>> "git branch -D".
>>>
>>> Rebasing and having a linear history is, in my opinion, much more
>>> important for long term maintainability than using standard git
>>> merging and being able to see that the exact commit went through
>>> (which may not be true since there could have been conflicts).
>>>
>>> Most of the time a rebase will be clean and the commits just go
>>> through, albeit with a new hash.
>>>
>>> Cheers,
>>> Damien.
>>>
>>>
>>>
>>> On Sun, Nov 22, 2015 at 8:44 PM, Mark Shannon <mark at hotpy.org> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Can I repeat my request that everyone uses the standard GitHub
>>>> mechanisms
>>>> for reviewing and merging code.
>>>> No one should merge their own code and *all* code should be reviewed
>>>> before
>>>> merging.
>>>>
>>>> Although my original reason for asking this is to democratize our
>>>> development process, there also practical reasons for asking.
>>>>
>>>> Using a standard git merge allows git to track which branches have been
>>>> merged, which makes it a lot easier to safely delete branches and
>>>> keep a record of work completed.
>>>>
>>>> If a branch is not merged cleanly then this:
>>>> $ git branch -d my-finished-branch
>>>> doesn't work and I need to manual verify that the branch has indeed been
>>>> merged and no commits omitted.
>>>>
>>>> Cheers,
>>>> Mark.
>>>> _______________________________________________
>>>> Microbit mailing list
>>>> Microbit at python.org
>>>> https://mail.python.org/mailman/listinfo/microbit
>>>
>>> _______________________________________________
>>> Microbit mailing list
>>> Microbit at python.org
>>> https://mail.python.org/mailman/listinfo/microbit
>>
>>
>>
>>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit



-- 
--Guido van Rossum (python.org/~guido)