Tracking Android kernel tips and Android builds

Zach Pfeffer zach.pfeffer at
Wed Aug 31 03:40:57 UTC 2011

On 30 August 2011 19:48, Alexander Sack <asac at> wrote:
> On Wed, Aug 31, 2011 at 2:09 AM, James Westby <james.westby at>
> wrote:
>> On Tue, 30 Aug 2011 11:10:10 -0500, Zach Pfeffer <zach.pfeffer at>
>> wrote:
>> > There's no reason to do it now, because its solving the wrong problem.
>> > The problem is sha's disappear. We use sha's because the provide
>> > immovable references to the state of a set of git trees so that people
>> > can reproduce builds exactly. We don't need the change to tag a build
>> > after its been deemed correct, we just need to implement a function to
>> > tag across the gits so that all the shas continue to exist.
>> I'm sorry, but I'm not sure what course of action you are advocating
>> here?
>> It sounds like you are advocating using a model where we use tags to
>> ensure that the referenced revisions are reachable from a head, and then
>> refer to the sha ids of the revisions in the manifest. Is that correct?
> I think what he is saying is that everytime we produce a pinned-manifest.xml
> we would at best be able to prevent those revisions from getting garbage
> collected.
> I think thats a reasonable vision in general. My main concern to start with
> is about tag inflation. Is there a thing like a 'hidden' tag in git that
> would allow that folks looking at a tree to still spot the 'real' tags and
> only see all the pinned/manifest tags upon request?

The tag thing is a means to an end, to keep the sha's around. If we
just tracked history trees we'd be fine, but all the rebasing causes
refs to become unreachable. All trees in Android should be history
trees so we shouldn't have a problem, but not everyone see's things
that way so we have the current disappearing sha problem.

> --
>  - Alexander

More information about the linaro-dev mailing list