Server side pull request merging

[Nick Coghlan]

On 16 July 2015 at 23:18, Mads Kiilerich <mads at kiilerich.com> wrote:
> We have heard (and given) the request before, but so far nobody have
> invested in implementing it. I would like to see it in Kallithea ... but
> probably in a way where it is optional.
>
> Server side merge functionality might be convenient but can also be
> considered harmful. It encourages a workflow where dirty history is merged
> ... and where the merges make the history even more dirty. Some people like
> that - I don't. I prefer to have a linear history - that is why we for
> Kallithea rebase (and polish) contributed patches before applying them. We
> would not use a "merge button" if we had one. At work we do merge and get
> dirty history, but the actual merge is just a small part of what is checked
> and done when merging to our mainline so doing it locally is no significant
> overhead and gives better insight into what actually is merged.

The all-singing-all-dancing idea I came up with last time:
http://lists.sfconservancy.org/pipermail/kallithea-general/2015q1/000231.html

Another way of doing online acceptance of changes is with rebases -
that's the way gerrit.beaker-project.org is configured. That way you
get the convenience of accepting changes online, while still keeping
the linear history on the main branch.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia