[U-Boot] U-Boot git usage model

[Wolfgang Denk]

Dear Stephen Warren,

In message <50759A75.8060105 at 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What about WRITING it first and rationalizing it afterwords?  :-)
                       - Larry Wall in <8162 at jpl-devvax.JPL.NASA.GOV>