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? > 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. Sounds a little bit like manual merge recording. > 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. Maybe merging stuff from different people is really (not yet?) practical, but imho something that really uses the commit ids and messages that are already existent would be pretty useful, so we can use the usual tools like git-log and git-bisect. Nico -- Think about Free and Open Source Software (FOSS). http://nico.schottelius.org/documentations/foss/the-term-foss/ PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
Attachment:
signature.asc
Description: Digital signature
