[Microbit-Python] Merging Pull requests.

[Mark Shannon]

On 22/11/15 23:01, Damien George 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".
That is all very well on your own private code base, but it doesn't work 
on a shared code base.
Who gets to rebase other people's branches and who doesn't?
Your approach just doesn't work if everyone is to be treated equally.

>
> 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).
History is not neat and linear.
What use is DVCS history, if not for working out how certain parts of 
the code came to be and who worked on them? If you linearise the 
history, then you can loose that.

>
> Most of the time a rebase will be clean and the commits just go
> through, albeit with a new hash.
Asking everyone to rebase their own branches before review will keep 
everything clean. It is also fair and transparent.

>
> 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
>