From: Takashi Iwai <tiwai@suse•de>
To: Nico -telmich- Schottelius <nico-linux-next@schottelius•org>
Cc: Stephen Rothwell <sfr@canb•auug.org.au>, linux-next@vger•kernel.org
Subject: Re: How to debug linux-next?
Date: Thu, 31 Jul 2008 18:36:38 +0200 [thread overview]
Message-ID: <s5h3alqko2x.wl%tiwai@suse.de> (raw)
In-Reply-To: <20080731160952.GB4291@denkbrett.schottelius.org>
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
next prev parent reply other threads:[~2008-07-31 16:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-31 12:56 xorg problems with v2.6.27-rc1-2457-gdcb80fd Nico -telmich- Schottelius
2008-07-31 13:23 ` How to debug linux-next? (was: Re: xorg problems with v2.6.27-rc1-2457-gdcb80fd) Nico -telmich- Schottelius
2008-07-31 13:35 ` Stephen Rothwell
2008-07-31 14:41 ` How to debug linux-next? Nico -telmich- Schottelius
2008-07-31 15:58 ` Takashi Iwai
2008-07-31 16:09 ` Nico -telmich- Schottelius
2008-07-31 16:36 ` Takashi Iwai [this message]
2008-07-31 16:54 ` Nico -telmich- Schottelius
2008-07-31 16:59 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5h3alqko2x.wl%tiwai@suse.de \
--to=tiwai@suse$(echo .)de \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=nico-linux-next@schottelius$(echo .)org \
--cc=sfr@canb$(echo .)auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox