[U-Boot] U-Boot git usage model

[Stephen Warren <swarren@wwwdotorg.org>]

On 10/10/2012 12:15 AM, Albert ARIBAUD wrote:
> Hi Stephen,
> 
> On Tue, 09 Oct 2012 17:04:06 -0600, Stephen Warren
> <swarren@wwwdotorg.org> wrote:
> 
>> On 10/09/2012 04:19 PM, Albert ARIBAUD wrote:
> 
>>> Apart from this, I'm not sure why forbidding fast-forward is a good
>>> thing, but if there are benefits, why not.
>>
>> 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.

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

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

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

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