[OE-core] [PATCH 1/1] kern-tools: checkpoint restoration for reset branches

[Bruce Ashfield]

On Wed, May 9, 2012 at 12:11 PM, Bruce Ashfield
<bruce.ashfield at gmail.com> wrote:
> On Wed, May 9, 2012 at 12:02 PM, Phil Blundell <philb at gnu.org> wrote:
>> On Wed, 2012-05-09 at 11:48 -0400, Bruce Ashfield wrote:
>>> On Wed, May 9, 2012 at 11:40 AM, Darren Hart <dvhart at linux.intel.com> wrote:
>>> >
>>> >
>>> > On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
>>> >> Updating the SRCREV to pickup the following fix:
>>> >>
>>> >>     createme: fix checkpoint restoration for reset branches
>>> >>
>>> >>     The meta branch can optionally be merged out to BSP branches. This removes
>>> >>     the need to restore the checkpoint when working with the tree.  The way
>>> >>     it detects the merge is by checking to see how many branches contain the
>>> >>     meta data. If there's more than one, the branch was was merged out.
>>> >>
>>> >>     Unless you are a BSP that isn't tracking the latest meta, and you get
>>> >>     meta and meta-orig created. That's two branches and the code opts to not
>>> >>     restore the checkpoint, which leads to configuration errors.
>>> >>
>>> >>     The fix is simple. We allow for 2 or less branches with meta, and will
>>> >>     still restore the checkpoint. Three and up, we won't.
>>> >>
>>> >
>>> > Uhm... am I the only one for whom this language is really confusing?
>>> > "merged out" ?
>>> > "restore the checkpoint" ?
>>>
>>> I could be more verbose, but it's like reading a kernel -mm commit. I
>>> don't grok everything they write, but they aren't writing it for me as a
>>> -mm newbie.
>>
>> So, who exactly is the target audience for the above text?  I'm not sure
>> that "really confusing" does it justice: from my point of view (though
>> admittedly I am very far from being an eleet k3rn3l h4x0r) it just looks
>> like gibberish.  If it's going into oe-core then I would have hoped that
>> the checkin comment would be intelligible to oe-core users at large, not
>> just those who are schooled in the mysterious ways of some particular
>> subgroup.
>
> It's a quote from the kern-tools commit log. I could just put: 'fixes stuff',
> but that's not good either. Writing a novel isn't good either.
>
> I'm not sure why everyone is having such an issue with this, there's many
> other examples of commits like this, and everyone sits in a glass house
> in this regard.
>
> I can re-work it of course, I wrote it very late at night to fix a

I rewrote the SRCREV update commit into something more legible. It's on
the same branch as the original pull request.

Cheers,

Bruce

> fairly blocking
> bug, so everyone cutting a little bit of slack would be appreciated.
>
> Cheers,
>
> Bruce
>
>>
>> p.
>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"