[PATCH] mq: Add mechanism for setting patch header contents

Peter Williams pwil3058 at bigpond.net.au
Sat Aug 22 20:02:08 CDT 2009

On 22/08/09 17:28, Dirkjan Ochtman wrote:
> On Sat, Aug 22, 2009 at 08:46, Peter Williams<pwil3058 at bigpond.net.au>  wrote:
>> # HG changeset patch
>> # User Peter Williams<pwil3058 at bigpond.net.au>
>> # Date 1250923379 -36000
>> # Node ID c4c1c8bd697f0e62c546740b8dc84b65990f2a6a
>> # Parent  37042e8b3b342b2e380d8be3e3f7692584c92d33
>> mq: Add mechanism for setting patch header contents
>> Modify 'qheader' by adding options rather than creating a new command.
>> Make sure that users will not be surprised by changes to 'qheader'.
>> Modification may be made to both applied and unapplied patches.
>> If the patch is applied, the change is not propagated into the change
>> set representing the patch but the user is warned that a refresh is
>> required for the propagation to occur.
>> Signed-off-by: Peter Williams<pwil3058 at bigpond.net.au>
> We don't do signed-off-by taglines in Mercurial.
> It occurs to me that your patch adds 4 levels of indentation to
> something that's already indented at one or two levels.

I'll see if I can fix that.

> That may well
> be alright, but it does make me a bit queasy about your patch. I'd
> also prefer to disallow this for applied patches; if you're doing it
> for applied patches, it seems like you might have newer patch data in
> your repo but newer metadata in the patch file, which seems ugly

 From my POV, the main purpose of MQ is the maintenance of a patch 
series and the fact that (from time to time i.e. when applied) the 
patches are in the repo is just an implementation detail so modifying 
metadata for applied patches makes good sense and isn't at all ugly.

Others may have a different view of MQ's purpose (and I myself use it 
for other purposes such as micromanaging development) but that doesn't 
invalidate my view of its main purpose.

I also think that making an EXCEPTION for applied patches is uglier.

> and error-prone.

Hence the warning.

But, I agree, it would be better if the changes were propagated to the 
change sets representing the patches straight away.  I currently don't 
have sufficient knowledge of hg internals to provide a patch to achieve 
this but think that it's possible and am working on it (if somebody 
doesn't beat me to it).  I don't think that it's important enough to 
delay acceptance of my current patch, though.

I'll submit a new version of the patch addressing the indentation issues 
that you raise (above) shortly.

Thanks for the feedback,
Peter Williams                                   pwil3058 at bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

More information about the Mercurial-devel mailing list