At Thu, 31 Jul 2008 16:41:11 +0200, Nico -telmich- Schottelius wrote: > > > > - And would a non-rebased tree not make life much easier for debugging > > > purposes? > > > > I don't know. What it would do is produce a lot more merge conflicts as > > patches are moved around, changed, removed etc on a daily basis. > > The only issue I see is with rewritten patches. Otherwise git-merge > should detect already applied patches and without git I see > git-format-patch and git-am as quite strong tools. > > I must confess, that I _really_ like the idea of doing > git-fetch && git-merge linux-next, so git-bisect works > for all versions. I also would love to have a continuous git tree, but I guess it's pretty hard for linux-next after some time. git-merge doesn't always track rebased trees perfectly, and we have also quilt trees in addition. Moreover, sometimes some subtrees have to be dropped temporarily for fatal conflicts. One thing I think sometimes useful is a record of HEAD of each merged tree in a file, say, Next/heads. Then you can see what changes have been done in each subtree more easily. BTW, you can try to merge the tree by yourself. For example, starting from next-20080729, merge next-20080730, resolve conflicts manually, and go next to 20080731. It seems working with a relatively small number of conflicts for a few days difference. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
