[PATCH] mq: Add mechanism for setting patch header contents
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