On 03/11/2010 07:54 AM, Nicolas Richard wrote:
Le 10/03/10 17:08, walt a écrit :
On 03/10/2010 03:03 AM, Nicolas Richard wrote:
So the general question is : if I want to use git-bisect (I have never
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 files
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 accident
because then I've made a permanent and unwanted change to my local copy of
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 <hexadecimal commit number> > 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 (noticed
it at the end).
Good observation. I see that /usr/local is the top line in /etc/ld.so.conf,
which I'd forgotten, assuming I ever knew it.
