bisect gives strange answer

I have been having lots of fun using 'git bisect' to find the commit that broke S3 wake on my laptop. But in its last step it gives an answer that cannot be right. I had not used git until now, so I may be missing something obvious: Corrections will be gratefully received. I'm using git from git

Re: bisect gives strange answer

> Could you try this please? Thanks, it now finishes with the diff that I expected: 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 is first bad commit diff-tree 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 (from a18bcb7450840f07a772a45229de4811d930f461) Author: Greg KH <[EMAIL PROTECTED]> Date: Wed Jul

Re: bisect gives strange answer

> By any chance, is this patch causing you problems? No, sadly. But I had hopes! As I think about it more, there's no way it could, since I have CONFIG_HOTPLUG=y, so moving the CONFIG_HOTPLUG would not change anything (for those who don't know the patch, it is appended below). My latest theor

Re: bisect gives strange answer

> Em, if you don't compile/test those intermediate versions, > how do you know whether to tag it good/bad ? Sorry, I wrote this part carelessly: "If I had checked out and compiled those intermediate versions from scratch..." I meant to emphasize the 'from scratch'. I did check out and compil

Re: bisect gives strange answer

> If you see any sort of evidence that this would hold true I really like > to know. I haven't found any evidence. When I rebuilt the kernels from scratch (exporting them into an empty directory using cg-export), I got reliable data and bisected down to a patch that probably was a problem. I wil

rc6-git8 Makefile from cg-export and bz2 patch don't agree

I wanted to get a clean 2.6.12-rc6-git8 tree, so I looked up the commit id (3edea4833a1efcd43e1dff082bc8001fdfe74b34) at , updated my .git repository with rsync -a --delete --verbose --stats --progress \ rsync://rsync.kernel.org/pub/scm/linux/

Re: Merge with git-pasky II.

> And that "where did this come from" decision should be done at _search_ > time, not commit time. I like this elegant approach, but clever pattern matching can help even at commit time. Suppose hello.c is simply: printf ("Hello %d\n", year); And then developer A updates hello.c to: printf

Re: Merge with git-pasky II.

> So until proven otherwise, I worry about accidental hashes, and in > 160 bits of good hashing, that just isn't an issue either...[Going > from 128 bits to 160 bits made it] so _unbelievably_ less likely to > happen that it's not even funny. You are right. Here's how I learnt to stop worrying an

Re: [PATCH] Pretty-print date in 'git log'

> ray:~/work/home$ date -ud 'jan 1, 1970 + 11 seconds' > Fri Mar 18 01:58:31 UTC 2005 > ray:~/work/home$ date -ud 'jan 1, 1970 + 11 seconds + 0800' > Fri Mar 18 09:58:31 UTC 2005 I sent David a short script to do almost that, except that mine needed to negate the timezone whereas y