On 6 October 2011 02:36, Tim Bird <tim.b...@am.sony.com> wrote: > On 10/05/2011 08:37 AM, Andy Green wrote: > > > Another side-issue is we are also looking at refactoring the > > Androidization patchset into topic branches, at the moment they're kind > > of reflecting the history that they were applied on plus or minus some > > munging around. So, all the net core patches for example would be > > together in one series, then all the wireless ones in a series on top of > > that, etc. It seems they would be easier to maintain then, opinions on > > that approach are also welcome. > > I've been working on a set of broken-out Android patches, in quilt format, > with exactly the same goal. It's much easier (at least for me) to maintain > the > differences as distinct patches using quilt, rather than as a series (or > set > of branches) of git commits. > > But possibly I'm just missing how to do this easily with git. > I would very much like to compare approaches, and possibly share >
Thanks a lot for the reply Tim. I can describe how I manage this flow in detail. Actually, since we would interact through pure git, it's not necessary to unify the patch management scheme to be able to cooperate. But since I spent so much time on exactly this subject I guess we both find it interesting to describe it. There are a number of valid ways to come at managing the topic patchsets and quilt is certainly one of them. Another approach that would work is to use git cherry-pick to throw around series of patches from one branch to another. The way I have been using though is stgit. stgit has the advantages of quilt in terms of managing itself the members of the series. If you try to do it with git cherry-pick, you have to have explicit secondary branches floating around to take the series from and keep tracking of what came from where and what basis it was on, etc, it doesn't seem it will scale well to dozens of topic and multiple branches. stgit has a further characteristic that it stores applied / pushed patches from the series in absolutely pure git commits, so at any time you can push what you have to remote git and that's exactly what people will pull with no stgit on their side. Stgit is like quilt in terms of patch stack operation, push, pop, float, "goto", support for rebase, re-ordering, apply conflict management, import, export, mail and so on. Stgit series, what is and is not applied, all state in fact, is bound to a specific git branch. So when you checkout a different branch in git, the stgit context for that branch is made active and nothing is lost about stgit in the previous branch. In that way, it's like some extra features integrated on top of git. Here's a tree I maintain with many topic branches using that flow http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking if you go back through the gitweb history, you can see it is formed from a set of other tracking-topic- branches each rebased on top of each other. I have a set of scripts to automate this rebasing. If I have something to fix or change at tracking-topic-hdmiaudio for example, I would move to that branch, change or add patches there, build and confirm the kernel works at that patchlevel, then use my scripts to rebase the topic branches on top of it, confirm we didn't break anything, and push the changed branches to public git. The main downside is management by stgit is slow. I have a fast build machine but stgit just uses one thread and favours correctness over speed, it's constantly checking to see if any files were changed behind its back in the tree for example. Fully rebasing all my trees is a matter of 90 minutes, although that includes a bunch of special rebase trees that are different from what we're discussing. The most important characteristic with managing the series at each topic level is that the topic patch series must strictly be sitting purely on top of the basis. git rebase, another candidate for handling the topic series, depending on the relationship of the two trees, will not always provide that feature in my experience. > the workload of maintaining such a thing. > That's great we have had the same thoughts looking at the same situation. What I am expecting is we get an easy ride until Linus kernel 3.1 release, at which point a backlog of disruptive patches will be applied to Linus HEAD for 3.2-rc0 and there is some work to do. We should keep in contact and figure out how to react to it when the extent of it is known. If it's reasonable amount of work I can take care of it, if it's getting a bit much it will be really great to be able to figure out how to share the load. Something else to consider about refactor scheme is when an official common-3.2 is coming say at 3.2-rc7. Unless we are able to interest common- maintainers in our scheme, that will not be structured according to our refactor. I gave this some thought, the worst that can happen is we have to discard the refactor and just take common-3.2 when the tracking basis is the same; consumers of the Androidization tree won't notice anything. More likely though, a large proportion of topic patches in, say, net core area are going to be unchanged or have minor tweaks. In that case, if we make sure that our tree and this first common-3.2 are on the same basis version, it should be possible to pick and adapt common-3.2 content on to the refactor and crucially, use git diff to confirm that the resulting tree is 100% identical at that point. So we can be certain that we have everything imported perfectly from the common- update even though the series is completely different. Thereafter, we can pick new patches going on common-3.2 one by one into the refactored tree. So, I think that case is probably manageable. -Andy -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
