contribution process

[Martin Geisler]

Alumni - pnathan <pnathan at alumni.uidaho.edu> writes:

> --- hg team has pruned itself to only consist of people OK to happy
> with mailing list based workflows. I (and many others through the
> years) have expressed their displeasure with it. I find github pull
> requests to be *excellent* and to generally move towards implementing
> them in corporate environments.

There are some problems in GitHub itself: comments on commits disappear
if the commits are rebased. It seems that this is simply because of the
data model -- the comment is still there if you recover the commit in
the web UI.

More fundamentally, there are (currently) some basic differences between
Mercurial and Git which make pull request work better for Git: the
ability to force-push in Git after changing the commits locally.


You cannot do that in Mercurial without evolve, and Bitbucket does not
support it for their pull requests. Bitbucket basically only supports
append-only changes to Mercurial pull requests.

Without the ability to re-publish a branch, the idea of code review
changes radically. Today, we can ask contributors to split commits, to
fix something in an early commit, etc.

With a code review workflow based on PRs on Bitbucket, this is no longer
a reasonable thing to do: the contributor would have to abandon the PR,
go strip the old commits from his Bitbucket fork, push the updated
changesets and then open a new PR.

So, for better and for worse, the Mercurial project maintains a clean
history. That fundamentally conflicts with the append-only fixes
supported by Bitbucket.

When evolve becomes mainstream enough for Bitbucket to support it, well
then things may change. But I wouldn't hold my breath for that :)

-- 
Martin Geisler

http://google.com/+MartinGeisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140703/ff053b18/attachment.asc>