Re: [PATCH] fetch2: Shorten long srcrevs

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Sun, 2013-05-19 at 14:32 +0200, Martin Jansa wrote:
> On Sun, May 19, 2013 at 01:21:55PM +0300, Richard Purdie wrote:
> > The long srcrevs are mainly used or the workdir construction as well as
> > the package version. The long entries are hashes generated by the git fetcher
> > and other scms using a similar revision mechanism.
> > 
> > We need these to change when the package changes however collisions are
> > unlikely to happen within the domains we care about. The long revisions
> > have generated negative user feedback due to the use in path and file
> > names.
> > 
> > This patch therefore truncates the revisions to 10 characters maximum.
> 
> What about 7 characters like git log --oneline is using?

git uses varying lengths depending on whether it detects collisions. I
really don't want to have to do the collision detection or worry about
this so 10 characters seemed like a nice number, its short enough to
address the complaints but long enough to avoid problems.

> SRCREVs in recipes are still supposed to be 40 characters for git,
> right? Because otherwise this part needs to be changed too:
> 
> lib/bb/fetch2/git.py
>             # Ensure anything that doesn't look like a sha256
>             # checksum/revision is translated into one
>             if not ud.revisions[name] or len(ud.revisions[name]) != 40 or (False in [c in "abcdef0123456789" for c in ud.revisions[name]]):

Correct, we still specify the exact revisions, this just truncates it
when its used in the user visible places like the version in the
directory name or package version.

Cheers,

Richard