Re: [git patches] 2.6.x libata updates

[Junio C Hamano <junkio@cox.net>]

Rob Landley <rob@landley.net> writes:

> grep -n MARKER bisect.patch | less
> (pick a line number)
> head -n linenumber bisect.patch > test.patch
>
> If that's not it, revert test.patch and then try again.  Tell us the first 
> line number that failed, which is the end of the patch we want...
>
> Hmmm...  The logical place to put the URL to gitweb is at the _end_ of the 
> patch, attached to the marker.  So that's what they see in the grep, and the 
> last thing they test when they cut at that line with head -n...

Well, do people realize that 'git bisect' is *not* a textual
half-way between, but rather is computed every time you feed
new "the patch you told me to test last time was good/bad"
information?  I do not think statically generating a huge text
and telling the user to apply up to halfway and bisect by hand
would not work -- it would be quite different from what git
bisect would give you.

I think public webserver based bisect service David Lang
suggests might work.  The interaction with it would start by the
end user somehow giving it the last known-working commit ID (A)
(pick from gitweb shortlog, perhaps) and a commit ID newer than
that that broke things (B) (again, pick from gitweb shortlog).
Then the service runs bisect on the server side, spit out a diff
against (A).  The end user applies the patch, try it, and then
come back and tell if it worked or not,...  Since we are talking
about the kernel development, I think the cycle might involve
rebooting the machine; so you would probably need two machines
(one guinea-pig machine to reboot, another to keep the browser
open so that your state can be kept somehow).