Messages in this thread | | | From | Junio C Hamano <> | Subject | Re: [git patches] 2.6.x libata updates | Date | Sun, 30 Oct 2005 23:46:45 -0800 |
| |
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).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |