From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nico -telmich- Schottelius Subject: Re: How to debug linux-next? Date: Thu, 31 Jul 2008 18:54:05 +0200 Message-ID: <20080731165405.GA4137@denkbrett.schottelius.org> References: <20080731125630.GB4201@denkbrett.schottelius.org> <20080731132344.GC4201@denkbrett.schottelius.org> <20080731233558.ba613f33.sfr@canb.auug.org.au> <20080731144111.GA4291@denkbrett.schottelius.org> <20080731160952.GB4291@denkbrett.schottelius.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Return-path: Received: from mx2.schottelius.org ([62.65.138.77]:57791 "EHLO mx2.schottelius.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752270AbYGaQyJ (ORCPT ); Thu, 31 Jul 2008 12:54:09 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-next-owner@vger.kernel.org List-ID: To: Takashi Iwai Cc: Stephen Rothwell , linux-next@vger.kernel.org --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > >=20 > > 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. > >=20 > > And dropping trees: Would not ignore those branches for > > merging help? Or if stuff has to be removed, to revert changes? >=20 > 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). > > > 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. > >=20 > > Sounds a little bit like manual merge recording. >=20 > The full merge log is found in Next subdirectory, but it's difficult > to find out the necessary information from the log text. >=20 > Suppose a list of tree and id pairs like >=20 > tree-a 012345 > tree-b 432100 > ... >=20 > then you can find easily which tree is changed by git-diff of this > file. That's exactly what I meant with manual merge recording :-) > > > BTW, you can try to merge the tree by yourself.=20 > >=20 > > 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. >=20 > 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). I am still not sure, what would allow me the easiest way of debugging, will perhaps have a deeper look at it later. > 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. Nico --=20 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 --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiR7i0ACgkQuL75KpiFGIwiRwCgvQLcf8GpmpvXT6iZGoQGwit3 QcEAni8ibBxLiW8iP77UVZzaJUcg/Rfj =jQj9 -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH--