On Sun, 2011-08-28 at 10:35 +0800, Andy Green wrote:
On 08/28/2011 05:20 AM, Somebody in the thread at some point said:
But I've got an open mind and am willing to try it out and figure out a workflow. I suspect for me it really won't be anything other then a different location to "git push" to.
I think we are having different takes on it (although I appreciate reading your somewhat nuanced view) because application of patches doesn't mean for me what it means to a history branch.
The patch does not just go on top of HEAD and then you're done, it needs to be placed at the right topic branch layer in tracking; may need to be adapted to apply to an intermediate branch (eg, tilt-3.0) that is on a different pinned release basis, then the intermediate branch rebased against the final basis like, eg, your android tree to provide the final output.
Right. So yes, the applying a series of patches directly to the tree isn't as big of a perk for your topic branches.
But... One way it can work is by applying them on top the gerrit head, you can then pluck them via git cherry-pick into your own tree and into the right topic branch. Then the next time you rebase/push, the patch should be included there. If gerrit provides a changeid on the merged patch (this I've not tried, so maybe it doesn't), it should then be able to track that the patch is also merged in your newly rebased HEAD.
But again, I really doubt there will be much in the way of kernel patches being submitted via gerrit (for most I suspect its more work to submit via gerrit then it is to mail patches). So I'd really only focus on gerrit as just a different public git repo to push your work to.
thanks -john