Strategies for push/merge problem?

[Peter Arrenbrecht]

On Tue, Jul 15, 2008 at 6:45 PM, Matt Mackall <mpm at selenic.com> wrote:
>
> On Tue, 2008-07-15 at 07:51 +0200, Peter Arrenbrecht wrote:
>> We all heard that Matt is not interested in the push approach. Fair
>> enough. So the question is, do sufficiently motivated people want to
>> take this into their own hands? I think it's not that hard to do as a
>> client and server extension, which could alleviate both the merge race
>> and the mergeful history problems. But, of course, a legimitate
>> question is if it stands a chance of getting official extension status
>> (Matt?).
>
> Doing merging on the server is not a good idea. Setting aside all the
> security and resource usage and complexity issues, it means that the
> resulting commit is not something anyone has ever even seen, let alone
> tested. And now it's in your history permanently. Who's name goes on
> that commit?

Matt, I concur with your points in general. But I think we're talking
more specific situations here.

I can see how merging on the server extends its attackable surface.
But this might be an option most useful in corporate settings and,
thus, on intranets anyway, or accessible only via ssh from trusted
parties. Furthermore, installing hooks on the server increases the
attackable surface in many ways anyway. But Hg supports this. The
point is, it's a conscious choice by the admin. But so would
installing the pushmerge extension be.

And I think there would be quite a few projects willing to accept the
resource usage and complexity (for the administrator and server box,
mind) if it makes life easier for tons of developers.

Finally, do you really think in the scenarios being discussed here,
developer X, who is simply pissed he has to pull and do a (to him)
pointless merge before being allowed to push, - and then maybe again!
- is going to run tests? When he knows perfectly well no one else is
changing his files, and the system is structured such that the chance
of him breaking the build or tests is practially zero? So it doesn't
matter if the server applies his name to the merge changeset, or he
does so himself on his box without running tests either. And he *did*
choose to run `hg pushmerge` in the first place, so it's not exactly
unforeseen.

I think this is crucial. We're talking - at least in part - about
situations where developers simply know they're not doing anything
stupid. But even then Hg refuses to accomodate them. So I have to
agree with Roman here. I think this is too rigid.

But please correct me if I did not understand your points fully.

-parren