mq: changeset timestamp after qfinish

[Kevin Bullock]

On 29 Jul 2011, at 10:52 AM, Giannini, Matthew wrote:

> I noticed today that when I finally finished some work I was doing in an mq patch and did qfinish to move the patch into my repository history, that the date for the finished changeset was the same as when I first imported the changeset into mq (which was several days ago).
>  
> It’s a little weird to see that the tip-most changeset has an older age than its predecessor. I was expecting the date to be the timestamp of when I did the qfinish.  Obviously, this is a minor issue, but I was wondering if you thought that my expected behavior was more intuitive and if mq should be modified for this behavior. 

Timestamps on commits are arbitrary—they're effectively user-supplied information—and there's no requirement they be monotonically increasing. By default, the date of the changeset created by MQ is the last time it was qrefresh'd (or qpush'd?).

If you think about it, this makes sense: you generally want the changeset to reflect the date and time it was finished, which without MQ is the same as when it was committed. It's only with things like `hg import` and MQ that finish-time and commit-time are different. If you want a patch to reflect the time you qfinish it, you should be able to just qrefresh it first.

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20110729/7128d941/attachment-0002.html>