About an IRC discussion on using pull requests for hg development

[Idan Kamara]

On Tue, May 8, 2012 at 12:23 PM, Martin Geisler <mg at aragost.com> wrote:

> Matt Mackall <mpm at selenic.com> writes:
>
> > On Mon, 2012-05-07 at 18:33 +0200, Patrick Mézard wrote:
> >> TL;DR:
> >> - Make history editing easier and safer (include histedit?)
> >> - Vague thoughts about supporting bitbucket-like pull requests while
> >> preserving an email-based review workflow.
> >
> > Every time this comes up, I say "but I do accept pull requests!"
> >
> > But I only want pull requests from people who have a track record of
> > getting a submission right the first time and have internalized
> > important rules like "don't mix unrelated changes". Otherwise I'll
> > start reading your incoming csets, discover problems, then ask you to
> > resend so I can comment on the problems. Which means my aborted first
> > pass was wasted effort.
>
> Yeah, I understand why this workflow requires nicely separated patches.
> I also agree that clean history is very valuable. I've been annoyed
> several times by now because largefiles were committed as one big
> changeset by that "Various" guy... he cannot be be trusted to write bug
> free code :)
>
> Maybe the problem is that we focus on the individual changesets and not
> on the succesion of branch heads?
>
> That is, maybe 'hg push' or 'hg pull' could add a marker to the new
> changegroup saying "these changesets came in together". Things like
> bisect could then operate on a changegroup level, maybe TortoiseHg would
> collapse the changegroups by default, ...
>

I'm not sure this will be a step in the right direction. It introduces some
new concepts which are non-existent in other DVCS and will probably
confuse new comers.


>
> The result might be a system where it's okay to use 5 half-broken
> commits to implement 1 new feature. I imagine that it would be possible
> to add more such group markers locally so that someone could push two
> groups to Bitbucket and ask you to pull them.
>

Do you really need that information in the main repo? I can see it
being useful when evolving a feature to a point where it can be
submitted but after that it's no longer interesting.

Recent example of mine, the implementation of 'commit --amend'
was initially in commands.py and later moved to cmdutil.py. Seeing
that information in the main repo doesn't serve anyone (as opposed
to having that information locally, which is useful, but currently sits in
the unusable patch repos).


>
> When you use pull requests in Bitbucket you don't see the diffs in the
> individual changesets: you see the combined diff. So that already
> encourages this view: if you're not happy with the diff, then you ask
> the submitter to reviese the pull request and he can do that by *adding*
> new changesets. Similarly to how we normally advertise 'hg backout' as
> the way to fix mistakes.
>
> --
> Martin Geisler
>
> aragost Trifork
> Commercial Mercurial support
> http://aragost.com/mercurial/
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120508/2c640130/attachment.html>