Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Keyword substituting with Mercurial

I would have a question on Mercurial with keyword expansion extension: is it possible to expand actual commit message with a keyword, so that it appears in sources for quick reference what's in the sources?

Edit: this seems to work:

in repo's hgrc

Log={desc}

But it doesn't stack, as it CVS counterpart allegedly does.

Use the Source, Luke:

Expansions spanning more than one line and incremental expansions, like CVS' $Log$, are not supported. A keyword template map "Log = {desc}" expands to the first line of the changeset description.

like image 724
Freddy Avatar asked Jan 20 '11 21:01

Freddy


1 Answers

Keywords can only expand on a single line, so you cannot get CVS-like behavior where the log messages keep accumulating. This is documented in hg help keyword after enabling the extension.

The commit messages are accessible with the {desc} template keyword in Mercurial, so you can add

[keywordmaps]
Log = {desc}

[keyword]
**.c =

to have $Log$ expanded line this in all .c files.

Note that the keyword extension gives a CVS-like view of the world in the way it operates on a per-file basis. Mercurial normally works on a repository-wide basis. If you do

$ hg commit -m "Fixed bug 123" foo.c    # create changeset 10:84e0d0dc9ce5
$ hg commit -m "Fixed bug 234" bar.c    # create changeset 11:2e85d7f2f93e

then it's correct that foo.c was last changed in revision 10, but it's wrong to say that revision 11 only contain bar.c. The foo.c file is also part of revision 11 — it is entirely plausible that the change to bar.c depends on the previous change to foo.c and so the snapshot in revision 11 captures the state of both foo.c and bar.c.

The keyword extension works on a per-file basis when it expands keywords: it will write $Log: Fixed bug 123 $ into foo.c and $Log: Fixed bug 234 $ into bar.c whenever you update to changeset 2e85d7f2f93e.

If you want to see why and when each file was last touched, then this will do what you want. If you want to know the global state of your repository — for example to use it as a version string! — then this is wrong. The problem is that your version.h file will be unchanged for long periods when you develop, and so the keywords in that file will remain unchanged too.

In that case you should really just run hg id as part of your Makefile. You can make it more fancy with something like:

$ hg parents --template '{latesttag}+{latesttagdistance}-{node|short}\n'

which will output a string like 2.1+117-eed1e5bba9a8. This means that your current version (eed1e5bba9a8), is 117 commits after the last tag (2.1). That makes it easy for users to compare builds made from the same central repository and you can still uniquely reproduce a build if you need to.

like image 191
Martin Geisler Avatar answered Nov 06 '22 23:11

Martin Geisler