Some notes about patches (was Re: [PATCH 1 of 1] record: allow splitting of hunks by manually editing patches)
Matt Mackall
mpm at selenic.com
Mon Feb 20 00:19:32 UTC 2012
On Sat, 2012-02-18 at 09:13 +0000, A. S. Budden wrote:
> On 17 February 2012 21:56, Matt Mackall <mpm at selenic.com> wrote:
> > On Wed, 2012-02-08 at 08:13 +0000, A. S. Budden wrote:
> >> # HG changeset patch
> >> # User A. S. Budden <abudden at gmail.com>
> >> # Date 1328644441 0
> >> # Node ID f63457e6722ba6e2a481ff963d57b98a63d68efc
> >> # Parent 878bc4a62a735a1624e9b69c672d5fb5074d4855
> >> record: allow splitting of hunks by manually editing patches
> >
> > First thing I ran into when trying to use this:
> >
> > diff --git a/README b/README
> > 1 hunks, 3 lines changed
> > examine changes to 'README'? [Ynesfdaq?] e
> >
> > cannot edit patch for whole file
> >
> > Seems we shouldn't offer the option if it'll never work?
>
> I agree. There's a second patch that sorts this out, but it was quite
> a big (and non-essential) change, so I didn't want to include it in my
> first submission. It's on the bitbucket link on the first email, but I
> can email it to the list if you prefer.
First, you sent a huge [0 of N] message; I generally don't even read
those(!) so I wasn't aware of the link.
Here's the history and the theory behind that last statement. The [0 of
N] message comes from the culture of the Linux kernel mailing list circa
2005 as a way to describe what you were doing in a series. But even in
2005, _they were deprecated_. The guy processing the bulk of kernel
patches in that era was Andrew Morton (who happened to sit in a
neighboring cube from me at the time). And he had come to the
realization that -if you had something worth saying about a patch, then
it ought to be in the commit message of the actual patch for posterity-.
So he'd gotten into the habit of manually cleaning up hundreds of
patches a month(!) by cutting and pasting from [0 of N] into the
relevant patch descriptions.
Eventually Andrew realized that he already had too much work to be doing
this sort of editing, so he started actively discouraging these [0 of N]
messages. Unfortunately the guy who wrote the patchbomb extension
emulating the LKML style didn't get the memo that [0 of N] was now
considered harmful, so we prompt for them by default. Presumably there
are now communities who like it, so much as I'd like to, I can't rip the
feature out.
As I'm much lazier than Andrew ever was, my approach to these message
over the years has now converged on: delete, then complain when
important data isn't available in the real descriptions.
ContributingChanges has this item in the submission checklist:
* all relevant info is in the commit message for posterity (not a "0 of
N" message)
Secondly, we'll always want patches to go to the list. I generally won't
even look at a patch on Bitbucket or the BTS: if I look at it, then I'm
reviewing it, and if I have review comments, I'll want to respond to
them inline, and that means finding raw patch text, cutting and pasting
in a format-preserving way, appropriately indenting so my comments can
be found, then inserting my comments. Or, asking people to send it to
the list, at which point I end up repeating all the cognitive work of my
first review. So it's better to not even start looking at it and ask
someone to get into the habit of sending everything to the list.
So yes, please send your patch for discussion.
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel
mailing list