On Sat, Aug 23, 2008 at 06:53:50PM +0200, Andi Kleen wrote: > > If you are thinking about 'linux-next', it is exception rather than > > the rule. > > No you're wrong. The majority of Linux trees I have to deal with > do it now and then. And I must say I also understand why > they want it -- they want a clean history on top of Linus' tree. > Otherwise there is no chance to find the own changes again > after a few thousands other merges. What I don't understand is in what context do you need to deal with "the majority of Linux trees"? Sure, the ext4 tree gets rebased all the time. But that's because it's a "leaf" tree; it means that people can't base development trees off of the ext4 tree as a result. But then again, that's not what the ext4 git tree is intended for! It's like in Java when you declare a class with the 'final' keyword; such classes can't be subclassed. The main use of the ext4 git tree is to allow people to more easily pull changes into their own trees, either for building their own integration trees, or their own personal private trees. It's simply a much more efficient way of applying a large number of patch queues. So for example, when I build my personal kernel that I use on my laptops, servers, et. al, I start with ext4 and pull in various "fixes" branches that I've needed over time to build a useful, stable kernel. So I have a personal merge script which does: git branch -f master linus/master git checkout master git merge tp_smapi-0.37 git merge remotes/libata-dev/upstream-fixes git merge remotes/ibm-acpi/for-upstream/acpi-release git merge misc-fixes git merge ext4dev ... and the result is an integration tree that always treet as throwaway, because I've merged in trees which are indeed throwaway. If I *do* any development work on this tree, say I cheat and fix some ext4 bugs on this tree instead of the ext4 branch, I always will go back to the ext4 branch, and use "git cherry-pick" to move those changes back to the ext4 tree. > > First, there isn't just _one_ way to deal with non fast-forward > > (rebased) branch; there are many possible workflow wrt rebasing. > > I don't doubt there are a million ways to do it somehow in > all kinds of convoluted ways. And that's exactly the problem. There are, but the simpliest way to win (as the movie "Wargames" put it), is not to play. Just don't put commits on top of a non-terminal trees; just use them to pull to create throw-away trees for building/testing, for integration testing or to build your own personal kernels. The only time when you really need to build on top of others' trees is if you have changes that depend on patches in another tree, which in practice should happen rarely; and if it does, you can ask the other maintainer to push the changes to Linus first. In that case, what you can do is put a placeholder patch in your tree, with a note in the commit log that this is a placeholder is pending someone else pushing the equivalent patch to Linus, and once they push it to Linus, when you do a rebase it will disappear. In practice, this happens so rarely that doing this manually with manual coordination between maintainers about who pushes a patch to Linus really isn't that big of a deal. - Ted -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
