linux-kernel - Re: Process to push changes to include/linux/types.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 15 Oct 2010 01:05:09 +0200 (CEST)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org,
	agruen@...e.de, davem@...emloft.net, andi@...stfloor.org
Subject: Re: 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.

Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/