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

Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to