Enable use and display of git revision numbers

[mcclure]

A thing I've noticed while using hg-git is that when I interact with git users, maybe I'll be talking to another developer or I'll be looking at the github page, periodically someone will say something about "revision 4898e" and I'll have no idea what that means and no way to look it up, because all the hashes in MY copy of the repository are in hg format. The git users and I do not have a common way of referring to revisions that we both understand, unless someone wrote really good commit messages. In an attempt to address this I made three changes:

• There is now an hg gsummary or hg gsum which prints the git-equivalent revision number (if any) of the current working directory state. It looks like:

git-rev: 4898e77458a287789dd5f42b51685f84d1fdf431

• You may now, in any hg command which would normally take an hg revision number, hg revision hash, or tag, just haul off and use a git revision number, like hg up 4898e to get the git revision from my example above.

(A small note: If you say hg up 4898e, and 4898e as a prefix just happens to match both an hg revision and a git revision, the current code will silently use the hg revision. You can specify you wanted the git revision by using a "g" prefix to the revision number, like hg up g4898e.)

• Most commands which show information about a changeset will now voluntarily mention the git revision number (if any) along with the tags, etc for that changeset. For example hg sum now looks like:

parent: 432:2740d263255c git:4898e77458a2 default/default/master default/master tip master Mercurial 1.8 compatibility for git-rev show branch: default commit: 1832 unknown (clean) update: (current)

And lines in hg log now look like:

changeset: 431:9d486e95cf37 git-rev: bd372664271b user: mcc <andrew.mcclure@gmail.com> date: Fri Sep 02 00:49:22 2011 -0700 files: hggit/__init__.py hggit/hgrepo.py description: git-rev code cleanup

The overall goal was to make addressing a revision by git-revision number as seamless as addressing it by tag or bookmark.

The patch also adds to the tests/ directory a small script I wrote named virtualenv-setup.py which uses virtualenv to locally deploy some self-contained copies of mercurial using specific known versions of mercurial and dulwich. This might be redundant with some of the existing test scripts but I found it helpful. I used this to test this checkin back to 1.8.

Does this sound good? Two caveats I have noticed:

• The hg sum / hg log additions only appear if you are not using styles or templates. I think this is desirable, BUT I think that some change should be made such that if someone wants to write a template which is aware of hg-git, there should be some way for that template to read the git-revision of a changeset it is displaying. I don't know a lot about the template system though so I couldn't really figure out how to do this (though I've made a post to the mercurial mailing list asking for help).
• For reasons I don't really understand, this doesn't work with hg outgoing. git revisions are not displayed in hg outgoing even if they are known.

EDIT: Here's my mercurial mailing list post btw, it includes gory implementation details for the above if that interests you. http://selenic.com/pipermail/mercurial-devel/2011-September/034064.html

[alanjds]

I feel that only having a single "g" to prefix can be not enough. In the case that rev g123whatever exists at GIT for example. It will be impossible to target that.

Maybe can be better with another prefix, maybe bigger ("git"), maybe with some char who can exist but is not used in fact ("g." or "g_").

What do you think?

[mcclure]

The git "revision numbers" (hashes, I've been imprecise) here are hexadecimal strings, so they cannot ever contain the letter g.

I did try using git: as the identifier prefix, like git:04cd3, but the colon appears to have a special meaning to hg and this did not work.

[alanjds]

Good! I did not realized that "pattern"... I tried git:02xyz too and found the same.

For now I am looking for some issue that stops me from pushing changes to my git server, but should be some extensions conflict. I'll investigate later.

[mcclure]

So to update, there was some discussion about this on the hg git google group / mailing list (where I posted the ~12 commits above as 3 patches broken down by feature). I believe the conclusion was that the "reference by git-id" patch was a candidate for inclusion but that my for printing git revisions in hg sum, hg log etc. was a little too brute force and I should instead explore an alternate method of inserting the git-rev information based on leveraging the hg template feature. However I don't know how to do this and I haven't since had sufficient time to research it. (In the meantime I've just been using my fork on my personal machines...)

If anyone with a little more understanding of Mercurial than me could assist with converting the git-rev display mechanism to use templates, I think it would help a lot with getting these changes integrated.

[davidmc24]

Had there been any further progress on these patches?

[mcclure]

Not really, no. The patches are still integrated in my personal fork ( https://bitbucket.org/runhello/hg-git/wiki/Home ) however, at some point after merges with trunk the update-to-revision feature broke (you can still read revisions using sum and gsum). I need to email the mercurial mailing list to get more information about how a plugin can make use of the templates.

[davidmc24]

Though I don't consider myself a Mercurial expert, I'm interested in helping to get some form of this feature working and integrated.

For commands that already support templated output, here are a couple examples of extensions that add new template keywords.

http://hgsubversion.googlecode.com/hg/hgsubversion/__init__.py (see the section with templatekw) http://hgsubversion.googlecode.com/hg/hgsubversion/util.py (see templatekeywords, svnrevkw, and related code)

https://bitbucket.org/durin42/hg-remotebranches/src/cec7524db873/hg_remotebranches.py (see remotebrancheskw)

For commands that don't already support templated output, one approach would be to try to add templating support. Matt posted with his thoughts on how that should be approached (archive link below).

http://mercurial.markmail.org/message/5rn22eludr5dcyn4

In terms of approach, I'd lean towards not changing the output of existing commands unless new arguments are given, in order to preserve backwards-compatibility. So, if the user runs "hg log" with a template that includes a git template keyword, or uses a new "--git" option, that's fine, but I wouldn't want "hg log" with no arguments to change its behavior. I started by trying out this approach with an extension to wrap the "hg identify" command to take a "--git" option (link to my patch queue below). It could use more tweaking to support additional combinations of options, but it works well enough as-is for the simple case (just wanting the git revision id).

http://mercurial.selenic.com/wiki/CompatibilityRules https://bitbucket.org/davidmc24/hg-git-queue

[durin42]

This is pretty stale and doesn't merge cleanly anymore. Open a fresh pull request if you feel like tackling this again, but it'd be worth talking on the hg-git list about approaches before doing too much work.