Mercurial Extensions using style templates and MacHg

Skip to first unread message

Jean-Luc Jumpertz

Oct 5, 2011, 4:46:05 PM10/5/11
to MacHg

I installed today the hg_timestamp_update extension (or more properly
speaking: update hook) in my system and wanted to make it work both in
my command-line environment and inside MacHg.The role of
hg_timestamp_update extension is to "set the modification-time of each
updated file to that of the last revision involving the file", so that
after cloning or updating a repository, you don't have all files set
to the same modification date.

OK, I know the reason why this behavior is not included in Mercurial
but franky, I find more convenient to see directly in the Finder which
files of my project have changed recently and which have not. And
running a "build clean" after an update or a pull does not harm after

Anyway, this was just for explaining the context of my message, to
clarify what follows (and not for starting a theological discussion
about the pros and cons of file dates!).

In order to retrieve the commit dates for the files,
hg_timestamp_update uses a custom style in the "hg log" command and
parses the output of this command. This style is defined in a template
file that is supposed to be placed in the mercurial/template
From what I read on mercurial's site and on other places on the
internet, there doesn't seem to be any mechanism in place to define an
additional template directory for this style feature, so you have no
other choice than adding the template file in your Hg installation.

As MacHg embeds its own local version of Mercurial, the only way I
found for making it work was to add the template file inside MacHg's
application bundle, which is obviously a highly non-recommanded way of
treating applications! ;-)

And the final point is that it is woking fine (after a few fixes in
the extension itself), but I will have to do this template addition
again and again, each time MacHg will be updated.

So if you have any ideas or suggestions of a better way of handling
this kind of situation, they are welcome!
On my side I may have 1 or 2 ideas to share on this subject and I
prefer to start the discussion in this group and to enter a bug/
feature request in the base only later, when the things will be


Reply all
Reply to author
0 new messages