On 05/08/2016 05:53 AM, Brian Dolbec wrote: > On Sun, 08 May 2016 11:06:09 +0100 > Amadeusz Żołnowski <aide...@gentoo.org> wrote: > >> I am working at the moment on debundling ejabberd. It will come with >> ~30 packages and I will do "git merge --no-ff ejabberd-debundled" >> because it will actually look less messy. >> >> Thanks, >> -- Amadeusz Żołnowski > > > Yes, this is exactly the type of merge commits that should be allowed. > > Not the one or two user PR commits that might be based on a weeks old > tree, that a developer merges without rebasing. It is these merge > commits which have caused all the grief we've experienced over merge > commits. > > Merge commits should be used wisely and for larger branch merges like > the kde, gnome team's development overlay merges to the main tree or > similar larger one off project's like the one above. It is these > larger commit branches that are much more difficult to "git pull > --rebase && git push --signed" successfully without some other pushes in > between causing a rejected non-fast forward push. > I think you touched on the key phrase we should be taking from the conversation: 'merges without rebasing'. Devs are encouraged -- if not required -- to push commits after rebasing, to ensure we're pushing to the latest HEAD and not something that's stale. If we hold merges to the same standard, would the problems that some have with merge commits disappear?
-- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
