On Mon, 2016-10-03 at 14:42 -0400, Bruce Ashfield wrote: > > > On Mon, Oct 3, 2016 at 1:07 PM, Cal Sullivan > <[email protected]> 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 <[email protected]> AuthorDate: Wed Sep 28 14:58:24 2016 -0400 Commit: Bruce Ashfield <[email protected]> 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 <[email protected]> On the old branch it was the commit that is now missing: commit 94e5bb30eaf8a880a6c82b64a497d8b4a855d138 Merge: d663231 7d1401a Author: Bruce Ashfield <[email protected]> AuthorDate: Fri Sep 9 11:33:07 2016 -0400 Commit: Bruce Ashfield <[email protected]> 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 [email protected] https://lists.yoctoproject.org/listinfo/meta-intel
