Ooops again! Sorry, this message was sent before it was finished.
Please ignore it. I will resend a good one latter.
Thanks,
Christian.
Le jeudi 5 avril 2007 10:01, Christian Couder a écrit :
> 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
> }
[...]
-
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