[U-Boot] U-Boot git usage model

[Stephen Warren]

On 10/11/2012 01:28 AM, Wolfgang Denk wrote:
> 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.

My experience doesn't agree. I almost exclusively use linux-next as the
underlying branch for all my development work. Now and then I do suffer
from finding the occasional problem, but it's better to find them and
fix them early rather than not seeing them until Linus merges everything
and having to debug through a couple months of history to find the bug,
so overall even that extra effort works out to be a net gain.

> 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.

(I assume that in "then next is not your choice" above, "next" is
referring to a linux-next style model)

Yes, with U-Boot's next model (or what I understand it to be...) a
linux-next style branch/model/.. is indeed not needed; just use
u-boot/next instead. At least, I think that's what you're saying.

>> 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.

Well, if git tells me someone committed something, it should be right. I
could apply just the same argument to writing the code; who cares who
wrote it so long as it's in the code-base?

Your assertion is probably coupled with U-Boot's interpretation of the
Signed-off-by tag too. Linux requires both the original author and each
committer/cherry-picker to sign-off the commit to document the entire
path the commit went through, In that scenario, a commit that has the
git committer field set to some value yet the last Signed-off-by entry
isn't that person is a red flag. Hence, the git committer field is
important.

However, U-Boot is reported to only use Signed-off to indicate the
original author(s), so I can see how the git committer field isn't
considered important in U-Boot. I'm not convinced it's a good idea to be
so cavalier about git metadata though; wouldn't it be better to take
simple steps (never rebase any other committer's commits) so that the
metadata is always correct?

>> 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?

Personally I believe it's a good idea to document the whole commit/merge
process fully. That's for all the same reasons that git contains
metadata for author, committer, datestamps, log messages, etc. The whole
point of source control is to document the development process;
otherwise, we could just publish the latest .tar and ignore git entirely.

...
>> 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.

If you have two commits or series that depend on each-other, e.g. series
A introduces a new feature and series B makes use of that new feature,
and those two series must be applied to different downstream trees for
some reason, then the process would be:

1) commit series A to downstream branch X
2) pull downstream branch X into u-boot/next
3) either re-create downstream branch Y from u-boot/next, or merge
u-boot/next into existing downstream branch Y
4) commit series B to downstream branch Y

The thing that makes this work easily in U-Boot is that the pull request
into u-boot/next in (2) above can basically happen any time, so it's a
very low-latency process. In Linux, there is only a specific time this
can happen (during the merge window), so the latency for such a process
is very high, and more convoluted processes much be followed for such
dependencies. I do like U-Boot's process better in this regard.