Based on the recent discussions we've had on this mailing list,
and the pain points experienced in moving from Dora to Dizzy, I think
it's best if we move to a release process that more closely matches
upstream Yocto Project and OE-core, where we fork a branch every time
a new release is created in upstream Yocto Project.
So, once v1.2 drops (week of 23rd March) I plan on moving the 'master'
branch of the luv-yocto repository to point at the 'master' branch of
Poky. The benefits are discussed in the thread referenced above but
mainly it allows us to pull new changes from upstream much sooner.
What this will mean is that after the v1.2 tag is created you'll see
something like the following when fetching updates,
$ git fetch
remote: Counting objects: 12698, done.
remote: Compressing objects: 100% (2537/2537), done.
remote: Total 10416 (delta 7720), reused 10409 (delta 7713)
Receiving objects: 100% (10416/10416), 2.60 MiB | 0 bytes/s, done.
Resolving deltas: 100% (7720/7720), completed with 879 local objects.
+ fd8d0b4...dda70ca master -> origin/master (forced update)
and a git pull will fail with a whole bunch of conflicts, because git
can't do a simple merge.
If you don't have any changes on your master branch the easiest way to
get upto date is to do,
$ git reset --hard origin/master
However, if you do have updates, before you do the reset you must save
them either by creating patches or stashing your changes.
Do not merge your old branches into the new master branch, the resulting
history will be an abomination, and explicitly contradicts what I'm
trying to do here - make it possible to merge upstream without causing
huge amounts of conflicts.
The old tip of the master branch will always be accessible with the
'v1.2' tag, so it's not like the history is going to be lost in any way.
Let me know if you have any questions.
Matt Fleming, Intel Open Source Technology Center