[U-Boot] U-Boot git usage model

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Stephen,

> >> It provides documentation in the git history of when merges were made,
> >> and what the source of the merge was (at least using the remote name
> >> that the merger has configured, which is better than nothing).
> > 
> > This is what it provides, but this does not tell me why it is a good
> > thing. My own use of git history is to find out which (local or remote)
> > branch --contains a given commit, and this is insensitive to allowing
> > ff merges or not.
> 
> The documentation of merge commits seems good to me just in an of itself.

"It's intrinsically good" sounds like a circular or axiomatic
justification to me.

> >> Related, not rebasing when merging a branch into upstream makes
> >> validating Signed-off-by a lot easier; when a patch is directly applied,
> >> it should be Signed-off-by the person who applied it. When a person does
> >> a rebase rather than a merge, the git committer for the commits is
> >> re-written as if the person doing the rebase applied the patch. Instead
> >> when merging (and disallowing fast-forward) a merge commit is always
> >> created so it's obvious where S-o-b should be applied (direct patch
> >> application) and where not (to commits that are merged).
> > 
> > I think we've got several things running here: merges with or without
> > ffs, hiding patches inside a merge (IIUC) and committer identity.
> > 
> > Re hiding patches in a merge if that's really what you mean, I agree
> 
> Hiding patches within merges wasn't something I'd considered at all; I
> just assumed that would never happen.

Good. Since we agree that patches never get hidden in merge commits,
then each patch always has its own commit with its "by" tags.

> ...
> > Re committer identity, I don't see the relationship with "by" tags, and
> > especially with Singed-off-by, since the sign-off is not and must not
> > be related to the committer of the patch, but to its author(s).
> 
> At least the way the Linux kernel uses the tag, both the original author
> of the patch /and/ anyone who applies the patch, cherry-picks the patch,
> ... must add their S-o-b line. I think U-Boot isn't using that part of
> the model.

No, it isn't. IIUC, U-Boot's "Signed-off-by" is supposed to mean "I
am (one of) the autor(s) of this patch".

> ...
> >>> Re merging from upstream back into downstream branches, I tend to think
> >>> that must be allowed considering custodian trees are supposed to be
> >>> useable, and as such may need to merge back from mainline.
> >>
> >> Why is that required for downstream trees to be usable? What is the
> >> definition of "usable" you're using?
> > 
> > See
> > <http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees#Philosophy_of_custodian_trees>:
> > 
> > "My idea of a custodian repository is that it is more than just a
> > working tool for collecting patches and preparing these for merge into
> > mainline. My idea is instead that these are pretty much independent
> > incarnations of U-Boot source trees which users (note: users, not only
> > developers) with specific needs or interests can refer to."
> 
> Hmmm. That makes custodian trees very multi-purpose; they have to both:
> 
> a) Be used for feeding patches upstream.
> b) Be a useful independent version of U-Boot.
> 
> That seems like conflating two pretty different requirements. I'm
> personally not sure that's a good idea.

Actually, b) is correct but a) is not how I would have expressed it, if
only because u-boot itself is a custodian tree, and u-boot-arm is both
feeding mainline and fed by other trees. How I would express it is that
a custodian tree:

a) feeds *from* patches and pulls (actually, fetches) from other
custodian trees;

b) is a useful independent (i.e. functional) U-Boot tree.

> Now, obviously the custodian trees should be buildable and run fine on
> all platforms; patches shouldn't break functionality. But, I don't think
> that any tree either that u-boot.git should be seen as somewhere you'd
> expect to be able to use a combination of features from different
> custodian trees before they're merged into u-boot.git, which is what the
> description above implies to me.

You're overspecifying the definition I showed you. It does not say
custodian trees should provide "a combination of features from
different custodian trees before they're merged into u-boot.git"; it
only says they should be "independent incarnations of U-Boot source
trees which users (note: users, not only developers) with specific
needs or interests can refer to". Not a word about having to combine
features. This you /can/ do, of course, in a custodian tree; but they
are not done for this purpose.

> ...
> > You may be making the point that next should be handled just as master
> > as far as the process I laid out can apply to next as well as master
> > only one release further -- and I might understand this. "Master" for
> > coming release, "next" for next release when merge window is closed,
> > and unruly topical branches for anythingthat does not fit in there.
> 
> Yes, using an identical process for next and master makes sense to me.
> 
> > But that's not making the point (IMO) that we should have a flurry of
> > branch names.
> 
> True, that's an entirely orthogonal issue. I mainly raised that point as
> an example from the kernel. What I really started this conversation
> about was not using rebases in either master or next, and the
> conversation has started to concentrate more on other things.

However, there are times when rebasing, and reordering even, might be
required -- think, for instance, of an important patch that should be
placed as early as possible in the next release, or inversely, a patch
that was put in next release and now sits in the middle of other
commits, but reveals faulty. There would be cause to pick this commit
out of the next tree before it becomes master.

Amicalement,
-- 
Albert.