[lkml]   [2010]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Process to push changes to include/linux/types.h

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-char
versions, they cannot become ambiguous at any time. If git also used
the initial portion of regular describes ("v2.6.24-1234-"), it would
be similarly strengthened. Yes, I'm just theoretically projecting
what 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 included
for 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 be
showing v2.6.22-9876-gxxx or anything further back in time.


 \ /
  Last update: 2010-10-15 01:07    [W:0.104 / U:3.964 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site