[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.098 / U:2.496 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site