Also, git-show-branch uses “transient” counting backwards from branches notation; unfortunately it is one of less known commands, and its output is a bit cryptic. It would be nice if git-log had switch which would function as if git-name-rev was specified as filter; the –decorate option only adds refs (heads and branches) markers in a way similar to gitk, qgit and gitweb.

As to git-describe output: it looks (by default) like this: v1.5.5-rc2-1-ge95d75d, which means 1 commit since version tagged v1.5.5, with shortened sha1 being e95d75d (with 7 characters it should be unique in most repositories). The sha-1 is needed because with multiple branches there can be, and usually are, more than one commit (revision) can be 1 commit after given tag.

As to being user-friendly… git still shows its origin as a bucnh of low level “plumbing” tools for hackers to use to build they own SCM scripts; it has much, much improved since.

Havoc: I kind of like having cryptographic checksums around for unique identifiers (they seem cooler than bzr revid’s, IMO); I just think an easily usable and manipulatable identifier is _also_ needed and that it should be just as prominent. I think hg had the right idea here, though I’d rather have something more meaningful and structural than simple 0…n.

Gabriel: Thanks.

James: I modified the post to fix the mistake (changing a couple “revisions” to “revision numbers”); let me know if I still missed anything. I did specify that revids were unique in the original text; was I not clear enough? Thanks for pointing out the issues.

tonfa: hg stores branch names under revision control too?!? Um, I guess that explains some comments I heard. Interesting; thanks for the explanation.

Jakub:

Cool, thanks for the pointer about git-describe. What does the shortened sha1 output by git-describe refer to? Also, I like how you put your numbering schemes comment; I should probably quote that in my post somewhere.

Should I have said more about the commit descriptions in git? I’m quite familiar with the transiency issues and git-name-rev (see http://www.gnome.org/~newren/eg/git-eg-differences.html#log). In fact, I don’t see the transience issue as a problem at all but a benefit (it makes it a lot easier to refer to “2 commits ago” than can be done in other systems where I first have to find out the current revision number) and it’s really just an extension of the idea of hg and bzr to use easy-to-use revision numbers that are only valid locally.

My issue with git here isn’t that git doesn’t have facilities for users to obtain useful information, it’s that it doesn’t bother helping users obtain it and learn the system. Personally, I don’t think the –decorate option to git-log is all that useful (except maybe in special circumstances), and even the documentation for git-name-rev suggests a non-optimal use. But even if –decorate was generally useful or the example command in the git-name-rev doc was the optimal one, the problem is that git passes up one of the best opportunities to give users easily manipulatable versions, teach them revision specifiers, and give them a small picture of the structure of the commits. While I’ve railed on git for being user-hostile, I really have found that git is quite close to being a friendly system like the others; it really doesn’t take that much to fix it up. A few small changes here and there (plus filling in a huge documentation gap) really does transform it from user-hostile to user-friendly.

So, I don’t see any reason to introduce all the additional complexity of some sort of custom textual encoding. Either way, the sha1 is unreadable and you’ll never type more than the first 5 chars of it.

BTW. there is yet another way to refer to revision (besides shortened sha-1), namely this returned by git-describe, in the form of closest tag + forward counting + shotened sha-1.

Note also that all numbering schemes either need central numbering authority (which repository we take those numbers from), or have to be local for a repository.

Afaik git branches is just a pointer to a particular head, no history is kept. There have been some talks in the Mercurial community to add “bookmarks” that would behave similar to that.

I think that the special naming for parents is quite nice, hg provides it with an extension (parentspec) for power users who wants it.

Another note about hg, is the possibility to use any non-ambiguous prefix of the hash as an identifier. I don’t know if other SCM uses this but ‘.’ can be used to identify the version you checkouted (working copy version).

BTW, I was going to send you a link to Chris Ball’s “Bugs Everywhere,” but I see you’ve all ready commented there Interesting stuff.