Subject: Re: How to debug linux-next?

From: Takashi Iwai <[email-masked]>
Date: Thu, 31 Jul 2008 18:36:38 +0200

At Thu, 31 Jul 2008 18:09:52 +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...

> > 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.

The full merge log is found in Next subdirectory, but it's difficult
to find out the necessary information from the log text.

Suppose a list of tree and id pairs like

	tree-a 012345
	tree-b 432100
	...

then you can find easily which tree is changed by git-diff of this
file.

> > 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.

I didn't suggest to keep maintaining self-made linux-next tree, of
course :)

Takashi