At Thu, 31 Jul 2008 18:54:05 +0200, Nico -telmich- Schottelius wrote: > > Takashi Iwai [Thu, Jul 31, 2008 at 06:36:38PM +0200]: > > Nico -telmich- Schottelius wrote: > > > Takashi Iwai [Thu, Jul 31, 2008 at 05:58:46PM +0200]: > > > > 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. > > > > > > Yes, imho rebase is something that must create pain, as it changes the > > > history (independent of git and linux). > > > For quilt, I did never use it -- not sure how those trees could be > > > integrated. > > > > > > And dropping trees: Would not ignore those branches for > > > merging help? Or if stuff has to be removed, to revert changes? > > > > Hm, what are the difference between them? Since linux-next is > > re-generated at each time, both should mean the same... > > A revert is recorded in the history. > A rebase isn't (and isn't thought to). Ah, so you mean to revert the whole tree commit? Not sure whether it looks nice... > > > > BTW, you can try to merge the tree by yourself. > > > > > > Well, yes, but that breaks my idea of having all trees based on the same > > > history: If I want to see, what the agp team did after v2.6.29 was > > > released and compare it to what I've -- I cannot do it, because their > > > v2.6.29 base is a different one than mine. > > > > Well, I meant you can try to get some continuous history by yourself > > to solve your problem. You know 20080729 is good, and 20080731 is > > bad, and you do want a continuous history between them. Then you can > > start from the good point and merge the next-tree itself manually > > until the bad point. > > That maybe a good idea to fix debug the issue now ... although > I still hope, we'll get a more generic way to fix such things > (-> when there are more linux-next testers, more such problems > will arise). Yes. > I am still not sure, what would allow me the easiest way of debugging, > will perhaps have a deeper look at it later. If it's about input-layer change like Andrew's case, Dmitry's patch should solve. Or, revert the commit 0571c5d20aca7... > > I didn't suggest to keep maintaining self-made linux-next tree, of > > course :) > > In fact, I am very happy for the work Stephen does. It really allows > testing new stuff quite easily. Definitely. 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
