On Friday 2010-10-15 00:13, Linus Torvalds wrote:>>Extended background for non-git people: git _internally_ only uses the>160-bit SHA1 (which in its full ASCII form is 40 hex characters). But>because that is so human-unfriendly, there are various human-readable>ways to express it.>[...]>   I tend to use the 12-character short version in commit messages,>for example. The full 40-character SHA1 makes it hard to do any sane>line breaks with in the commit message.I tend to use describe --tags (rev expr) output; unlike 12-charversions, they cannot become ambiguous at any time. If git also usedthe initial portion of regular describes ("v2.6.24-1234-"), it wouldbe similarly strengthened. Yes, I'm just theoretically projectingwhat happens if \lim_{time,hackers -> \infty}...>It's worth noting that the "v2.6.24-6165" - while human-readable and>thus useful - is technically meaningless. Since development isn't a>straight line, "6165 commits after 2.6.24" is really not a>well-defined point.It could be - in totally linear developments. (Postgresql, anyone?)>In contrast, the "v2.6.25-rc1~1089^2~98" expression is actually>well-defined. There is no ambiguity there, but it's also obviously not>really all that human-readable.I beg to differ. It tells you that the certain commit was includedfor v2.6.25-rc1. That's much more telling than v2.6.24-1234-gabcdef1.Especially when a branch has not been recently merged, it could beshowing v2.6.22-9876-gxxx or anything further back in time.Jan