[Python-Dev] hg diff

[Antoine Pitrou]

On Mon, 7 Mar 2011 13:04:11 -0500
Barry Warsaw <barry at python.org> wrote:

> On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
> 
> >On Mon, 7 Mar 2011 12:04:18 -0500
> >Barry Warsaw <barry at python.org> wrote:
> >> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
> >> 
> >> >If we can get to a mode where non-committers can push to a "fork" on
> >> >hg.python.org, we can dodge the patch format issue by having folks post
> >> >"pull requests" for that fork instaed.
> >> >
> >> >For the repoze and pylons projects, we have found the quality and
> >> >quantity of patches went up *significantly* when we made it easy for
> >> >somebody who doesn't work on the code all the time to use this workflow
> >> >(fork to a public repo, clone, hack, commit, push, request a pull).
> >> 
> >> +1.  'Branches' are better than patches.
> >
> >How do you review a branch?
> 
> You can merge it locally and look at the diff.  Or use Rietveld if that's
> supported.  But the reason a branch is better is because it's easier to track
> the submitter's changes in response to your review comments, and it's easier
> to make changes to their branch and push an update for *them* to see.

I agree with Thomas' answer here: while a branch makes it easier to
maintain a patch (but you can also use e.g. Mercurial Queues), it
doesn't make it easier to *review*.  You are assuming that I, as a
reviewer, want to know about the history of changesets that led to the
patch, but I don't: I want to read the patch as a cohesive whole, and I
couldn't care less about the various typo fixes, style changes,
performance tweaks that were checked in all along.

So, I'd rather have the submitter post a patch, than generate it
myself. Meaning that if I have to generate it myself, I might be too
lazy (or overworked) and not do a review at all.

Regards

Antoine.