From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 10 Oct 2012 10:04:28 -0600 Subject: [U-Boot] U-Boot git usage model In-Reply-To: <20121010081501.34316516@lilith> References: <201210072049.00393.marex@denx.de> <20121009142304.GA16530@bill-the-cat> <50749120.1070703@wwwdotorg.org> <20121009213208.GE1137@bill-the-cat> <20121010001912.6f15bb8d@lilith> <5074AD66.5020501@wwwdotorg.org> <20121010081501.34316516@lilith> Message-ID: <50759C8C.3030509@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 10/10/2012 12:15 AM, Albert ARIBAUD wrote: > Hi Stephen, > > On Tue, 09 Oct 2012 17:04:06 -0600, Stephen Warren > 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 > : > > "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.