On 16 July 2015 at 23:18, Mads Kiilerich <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ kallithea-general mailing list [email protected] http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
