Dear Stephen Warren,
In message 50759A75.8060105@wwwdotorg.org you wrote:
Do note that linux-next doesn't become the next Linux kernel version either; it's just a preview of the merges Linus will do. Linus re-does all the merges based on the pull requests people actually send him. So, the model is very different to u-boot/next.
Yes. And experience has shown that linux-next may be useful for specific testing, but it is utterly useless as base for any development work. When you need a tree which has all the latest and greatest commits (which have already been accepted for inclusion into the next release), then next is not your choice, because it will crumble below your fingers.
If I run "git log u-boot-xxx/master", and look backwards through the list of commits, looking for those committed by the owner of u-boot-xxx,
Who cares about the comitter? This is just a technical act. It makes zero difference whether I apply a patch or somebody else applies the same.
and stop when I see a commit by someone else, I'll end up stopping at the merge commit where u-boot/master was merged back down. If there commits to u-boot-xxx/master between the point where u-boot/master merged u-boot-xxx/master and where u-boot-xxx/master merged u-boot/master back down, then they'll be hidden before that merge point.
I have to admit that I never ever cared about any merges before. For me they happen because of that's the way how development goes, i. e. they cannot be avoided, but that's all. I have only been interested in which commits have ben included, not which branch or repository these have been coming from.
Why would I need to know that?
In either case, one must always wait for the pull request send in (b) to be completely merged so that when the pull request is merged, it doesn't pick up commits to the branch that were added after the pull request was sent. So, there isn't a tree ready to take new patches until a pull request has been completely processed.
Usually pull requests get handled very quickly.
Since u-boot/next appears to be a rolling/parallel model, where changes can be pulled into it at arbitrary times even when u-boot/master is being used to stabilize a release, the way to resolve conflicts for U-Boot is simply to have the branch containing the dependency push their /next into u-boot/next, then the branch needing the dependency to branch from or merge u-boot/next into their /next, then apply the patch with the dependency.
Sorry, I cannot parse this.
Best regards,
Wolfgang Denk