About an IRC discussion on using pull requests for hg development

[Martin Geisler]

Benoît Allard <benoit at aeteurope.nl> writes:

>> 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, ...
>>
>> 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.
>>
>> 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.
>
> You are probably looking at the group extension.
>
> http://mercurial.selenic.com/wiki/GroupExtension

Thanks -- I should have mentioned that I'm aware of that extension.

I was talking about a core feature, but maybe the extension can be used
as a basis for experimenting with this. Maybe it will all bee moot when
Pierre-Yves's work on obsolute changesets bears fruit: then people can
rewrite history and mark the old changesets as obsolete and they'll
eventually disappoear.

-- 
Martin Geisler

aragost Trifork
Commercial Mercurial support
http://aragost.com/mercurial/