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:
hg up 4898e
(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.)
hg up g4898e
parent: 432:2740d263255c git:4898e77458a2 default/default/master default/master tip master
Mercurial 1.8 compatibility for git-rev show
commit: 1832 unknown (clean)
And lines in hg log now look like:
user: mcc <email@example.com>
date: Fri Sep 02 00:49:22 2011 -0700
files: hggit/__init__.py hggit/hgrepo.py
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
Minimal 'hg summary' command
Working overload of 'lookup' to support git revisions (preferably pre…
…fixed with 'g')
Don't match on git revisions that don't exist in hg
muck with ui to add git-rev: line, but git-rev shown is not correct yet
Working git-rev print on hg sum, hg log, etc
Skeleton of a virtualenv setup script
virtualenv script loads dulwich and loads appropriate mercurial
virtualenv-setup.py under tests now works
git-rev code cleanup
Mercurial 1.8 compatibility for git-rev show
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?
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.
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.
Merge github/mcclure version of git-rev integration with github head
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.
Had there been any further progress on these patches?
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.
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).
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).
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.