The Mercurial MQ extension does not store the creation date of a patch by default. This behavior can be changed but what about existing patches? If the patch queue is under version control it might be possible to restore at least some information.
In course of working on the CACAO VM I was forced to use mercurial for the first time. Being a self-confessed git enthusiast it was hard to give away most of the power over the history. After messing up the repository meta data several times using extensions like rebase and histedit I finally gave the MQ Extension a try.
I really like(d) the fact that its all about plain patches with only minimal meta data.
Unfortunately the creation date is also excluded by default. This can be changed by
adding the command line flag
-D/--currentdate to the
hg qnew and
commands (or even create an alias). There is still another problem with
as it refreshes not only the patch but the also the date.
This FAQ entry
on the MQ Extension page provides a solution to the issue.
But it those not bring back date information for old patches. In my case a few months and ~230 patches worth of date information.
Fortunately not everything was lost. I put my patches under version control right from
the beginning (the
hg commit -mq command makes it really convenient.).
I to commit my changes at least once a day. Therefor, the creation date of each
patch file is stored in the queue repository. The
hg log command together with
some revset magic reveals the information:
1 2 3 4
It returns the modification dates in chronological ascending order.
To get the date format desired for the patch meta data the
hgdate can be used:
1 2 3 4
The following script is intended to be run inside the patch directory (e.g.
greps for all patches without a
# Date, fetches the creation time from the patch
repository and insert it into the patch file.
Please always do a
hg commit --mq and
hg push --mq to backup you patches before
1 2 3 4 5 6 7 8 9 10 11 12
The date is always inserted on the 3rd line. This might be a problem in some scenarios. If the commit frequency in the patch repository low, you don’t get much useful data. Renamed and folded patches do not work.
As always, this information is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. Kittens may die if you don’t read the manual and know what you are doing.
It seems that the MQ Extension does not really fit my needs after all. The mercurial community has its own way of dealing with safe history editing, called ChangesetEvolution which centers around phases, histedit, evolve, rebase and other extensions. This is probably the right way of doing history editing things with mercurial.