On Mon, 2016-10-03 at 14:42 -0400, Bruce Ashfield wrote:
>
>
> On Mon, Oct 3, 2016 at 1:07 PM, Cal Sullivan
> <california.l.sulli...@intel.com> wrote:
> + Bruce
>
> I also can't find that revision on the remote branch...
>
>
> There were some fixups lately, but yah, I don't see that revision
> either. One of the
> rebase branches was force updated for those cleanups, but not
> standard/intel/base.
Are you sure?
The last common commit between "old" standard/intel/base (the one with
94e5bb30e) and "new" standard/intel/base (where that commit is not on
the branch) is 7d1401a0dd9bebfe49937ca7d9785972e0cc76d0.
The first child of that commit on the new branch is:
commit 6325d22ec66be98675f41d769cdf935635fcb0e4
Merge: 7d1401a 1d074db
Author: Bruce Ashfield <bruce.ashfi...@windriver.com>
AuthorDate: Wed Sep 28 14:58:24 2016 -0400
Commit: Bruce Ashfield <bruce.ashfi...@windriver.com>
CommitDate: Wed Sep 28 14:58:24 2016 -0400
Merge tag 'v4.4.21' into standard/base
This is the 4.4.21 stable release
Signed-off-by: Bruce Ashfield <bruce.ashfi...@windriver.com>
On the old branch it was the commit that is now missing:
commit 94e5bb30eaf8a880a6c82b64a497d8b4a855d138
Merge: d663231 7d1401a
Author: Bruce Ashfield <bruce.ashfi...@windriver.com>
AuthorDate: Fri Sep 9 11:33:07 2016 -0400
Commit: Bruce Ashfield <bruce.ashfi...@windriver.com>
CommitDate: Fri Sep 9 11:33:07 2016 -0400
Merge branch 'standard/base' into standard/intel/base
To me this looks like some work was done based on an old commit and then
the resulting branch was force-pushed.
Please don't get me wrong, I'm not trying to blame anyone. I'm just
trying to figure out:
1. How we can make commit 94e5bb30ea a part of the branch again so
that current users of it can build from upstream source again.
2. How such incidences can be avoided in the future.
> Either way, I sent a pull request late last night that has the
> revisions I've been testing
> so they should work.
Do you have a pointer to that for me?
If it does not include 94e5bb3 and force-pushing the original
standard/intel/base branch isn't an option, then I could fabricate a
fake merge commit (one that doesn't change the tree) with the branch
head and 94e5bb3 as parent. Then 94e5bb3 is part of the branch again and
the fetcher will be happy.
Regarding preventing such incidences, can kernel repos like
git.yoctoproject.org/linux-yocto-4.4.git be configured so that no-one
has the rights to force-push branches that aren't meant to be rebased?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
_______________________________________________
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
