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,