Le jeudi 29 mars 2007 08:06, Junio C Hamano a écrit :
[...]
> The thing is, the more you add policy to a building block, the
> less generally useful the building block becomes. The reason I
> took "git bisect run" is because for the simplest use case, it
> can be used without writing a specialized "run script" (you can
> give "make test" to it, for example). And more importantly, in
> the case of "run", there is not much policy involved. It is a
> good command to have in a building block because what it does is
> purely to automate what the user would perform mechanically by
> hand anyway. One thing I would want is to keep the bisect
> subcommands to the minimum, so that people can easily use it as
> a building block in their automation, without having to hunt
> through many workflow-specific subcommands that do not suit
> their particular needs.
I understand this.
> Catering to their particular needs are
> better handled in their scripts, including your "I have one
> known good commit, I do not know if the tip is good, and I want
> to dig down from the tip only when the tip is bad" case.
But I think this is not a specific need. Many people are doing nightly
builds and it's a good practice, so we should encourage them by making it
as easy as possible.
Perhaps a new git subcommand instead of a git bisect subcommand.
For a nightly build you want to do something like:
my_build_script || {
git bisect start &&
git bisect bad &&
git bisect good good_rev &&
git bisect run my_script
}
> If you want to add value to bisect, here are two I can think of,
> one almost trivial, and the other a bit harder.
>
> (1) One bad commit is fundamentally needed for bisect to run,
> and if we beforehand know more good commits, we can narrow
> the bisect space down without doing the whole tree checkout
> every time we give good commits. I think it may be a good
> idea to have:
>
> git bisect start [$bad [$good1 $good2...]] [-- <paths>...]
>
> as a short-hand for this command sequence:
>
> git bisect start
> git bisect bad $bad
> git bisect good $good1 $good2...
>
> That would be a good script-shorterner, without limiting it to
> any specific use scenario.
>
> (2) There is no technical reason to have a good commit for
> bisect to run, other than you _often_ do not want the first
> mid-point checkout before you give good ones to it. But
> sometimes, you may not know even if something _ever_ worked,
> IOW, even the root commit might not be good. In such a
> case, being able to bisect having only one bad commit and no
> good commit would be handy. For this, bisect_next_check
> needs to be tweaked. Probably a transcript for such a
> feature would go like this:
>
> $ git bisect start
> $ git bisect bad HEAD
> $ git bisect next ; echo $?
> You need to give me at least one good and one bad revisions,
> with "git bisect good" and "git bisect bad".
> 1
> $ git bisect next --without-good
> Bisecting: 4321 revisions left to test after this
> [deadcafedeadcafedeadcafedeadcafedeadcafe] an ancient commit
> $ git bisect bad
> Bisecting: 2152 revisions left to test after this
> [edeadcafedeadcafedeadcafedeadcafedeadcaf] a more ancient commit
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html