Dear developers and users, After merging patches directly on my git tree, I was impressed by the number of things I discovered that I should not do when handling it ;) Living and learning :) There are lots of trash there, due to the way patches get merged back from upstream. As reverting a patch there will break things for everybody that clones from my tree, I decided to go to an easier way: let's start from scratch. I've created a new tree, at: http://git.linuxtv.org/media_tree.git Currently, it is just a clone of Linus tree, all pointing to v2.6.35. I'll soon be adding more patches there. In order to avoid the same kind of troubles I had in the past, I intend to use the following guidelines: 1) branch "master" - will have the contents of Linus tree. 2) branch "staging/2.6.35" - will have patches for the current stable kernel; 2) branch "staging/2.6.36" - will have patches for the current development cycle; 3) branch "staging/2.6.37" - will have patches for linux-next On every new kernel release, I'll create another branch. No branches will be rebased, but I won't merge from a staging branch into master. If needed, I'll just update master to from Linus tree after having a changeset pulled there. As need arises, I'll be adding some development branches there with stuff that are already accepted, but there are still pending patches that are needed before sending that patch set upstream (for example, new internal/external API's added, while there's no driver actually using them). For those that already sent me pull requests, and for a few weeks, there's no action need. I'll be manually handling the tree differences for a while. Yet, the better is to rebase your trees using the new one as the basis. Except when needed (like depending on a third-party patch applied on my tree), the better is to have your local git trees always based on master. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
