From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NptSs-0003PI-D5 for garchives@archives.gentoo.org; Fri, 12 Mar 2010 01:14:58 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6B6ADE0982; Fri, 12 Mar 2010 01:13:56 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 23DD6E0982 for ; Fri, 12 Mar 2010 01:13:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id BDFB51B40A3 for ; Fri, 12 Mar 2010 01:13:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.992 X-Spam-Level: X-Spam-Status: No, score=-2.992 required=5.5 tests=[AWL=-0.393, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDs-9Ub7EM16 for ; Fri, 12 Mar 2010 01:13:48 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id 6BDDC1B4096 for ; Fri, 12 Mar 2010 01:13:47 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1NptRc-0000ww-VX for gentoo-user@gentoo.org; Fri, 12 Mar 2010 02:13:40 +0100 Received: from adsl-69-234-193-245.dsl.irvnca.pacbell.net ([69.234.193.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Mar 2010 02:13:40 +0100 Received: from w41ter by adsl-69-234-193-245.dsl.irvnca.pacbell.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Mar 2010 02:13:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: walt Subject: [gentoo-user] Re: how to "git-bisect" in a portage-compatible way ? Date: Thu, 11 Mar 2010 17:13:25 -0800 Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: adsl-69-234-193-245.dsl.irvnca.pacbell.net User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a3pre) Gecko/20100311 Thunderbird/3.2a1pre In-Reply-To: Content-Transfer-Encoding: quoted-printable X-Archives-Salt: d2d23416-2ea0-4f4a-a37d-41e74f04f8b5 X-Archives-Hash: 31373b5e97a41c3c287caa58909e64c4 On 03/11/2010 07:54 AM, Nicolas Richard wrote: > Le 10/03/10 17:08, walt a =E9crit : >> On 03/10/2010 03:03 AM, Nicolas Richard wrote: >>> So the general question is : if I want to use git-bisect (I have neve= r >>> done that before, but today is a good time to try), >> >> It's a great tool and easy to use once you've learned the basic steps. >> You can ask here if you need help with it. > Let me stop being off topic for a few seconds, and ask a real question > about git-bisect : imagine there are two bugs : bug A is a known bug, > present in version 2.4.11 but corrected in 2.4.18, and bug B is another > bug which I'm trying to bisect. Problem : they have the same effect > (let's say : a crash) and I want to fix bug A because it might hide bug > B. Assuming that the patch which fixes bug A can be applied to the file= s > of versions 2.4.11-2.4.18, is it possible to bisect these modified > versions ? > What I can imagine is : do a normal git-bisect session, but each time > apply the patch before ./configure'ing. That sounds ok, but is it ? I seem to recall doing something like that once, but I can't remember how it turned out :o) Not every file in your git working directory is over- written with each 'good' or 'bad' bisect step, so your patch may possibly be rejected as 'reversed' on some iterations of bisect. That is to be expected. > And > if yes, what's the correct way to tell git to "put the changes induced > by one commit on the current head" ? (I hope I'm being clear and not > mixing the terms, here). Hm. I'm not sure what you are asking. I'm not a developer but I do often apply patches from developers and I try to avoid making commits by accide= nt because then I've made a permanent and unwanted change to my local copy o= f the remote git repo. For example, if I want to apply a bugfix from 2.4.18 to a working copy of 2.4.11, I would first check out a copy of 2.4.18 and then generate a patch file by using 'git diff -p > test.patch= ' (assuming that you know the commit number of the bugfix, of course). Then check out a working copy of 2.4.11 and apply test.patch to it. The patch may or may not succeed, of course. If the two versions are far enough apart in time, such patches will fail quite often. That's when you start contacting the upstream devs to get their advice/flames. When you are done fiddling with patches you can do 'git reset --hard' to restore a pristine working copy of the git repo. An alternate method is to create a new branch for all your fiddling, e.g. 'git branch junk' and then git checkout 2.4.11, or whatever, and then delete 'junk' when you're finished with your fiddling. I seem to recall that real devs use that method, but I could be mistaken. > Actually, it seems that the system first looks in /usr/local/lib before > /usr/lib, so it was probably unnecessary to modify the symlinks (notice= d > it at the end). Good observation. I see that /usr/local is the top line in /etc/ld.so.co= nf, which I'd forgotten, assuming I ever knew it.