Jeff King writes:
> I do think that accessing the bisect/bad ref is a little intimate with
> the implementation (i.e., it implies knowing that there is only a single
> "bad" that we are moving around, unlike "good", where we may mark many
> such tips).
I actually do not think it is merely an imp
On Mon, Jun 24, 2019 at 09:16:13AM +0200, Christian Couder wrote:
> So you just need to parse stdout to detect that it found the first bad
> commit, and then you can use refs/bisect/bad.
>
> If the return code was used, how would you distinguish between a
> failure in the command (for example if y
On Mon, Jun 24, 2019 at 11:41:53AM -0700, Junio C Hamano wrote:
> > I think it might be nice for Git to write a well-known refname (like
> > BISECT_RESULT or similar) so that you can refer to that instead of
> > having to read stdout (whether by machine or by a user
> > cutting-and-pasting). And I
Jeff King writes:
> On Sun, Jun 23, 2019 at 01:32:16PM -0700, Pedro Larroy wrote:
>
>> Thanks for your answer.
>>
>> I was expecting the HEAD to point to the first bad commit.
>>
>> In mercurial, the exit status tells you information about the
>> bisection process: https://www.mercurial-scm.or
On Mon, Jun 24, 2019 at 4:51 AM Jeff King wrote:
>
> On Sun, Jun 23, 2019 at 01:32:16PM -0700, Pedro Larroy wrote:
>
> > Thanks for your answer.
> >
> > I was expecting the HEAD to point to the first bad commit.
> >
> > In mercurial, the exit status tells you information about the
> > bisection pr
On Sun, Jun 23, 2019 at 01:32:16PM -0700, Pedro Larroy wrote:
> Thanks for your answer.
>
> I was expecting the HEAD to point to the first bad commit.
>
> In mercurial, the exit status tells you information about the
> bisection process: https://www.mercurial-scm.org/repo/hg/help/bisect
>
> Su
Thanks for your answer.
I was expecting the HEAD to point to the first bad commit.
In mercurial, the exit status tells you information about the
bisection process: https://www.mercurial-scm.org/repo/hg/help/bisect
Sure one can parse stdout, it's just more tedious than just checking
the return c
Pedro Larroy writes:
> I'm using git bisect, and for complex reasons I can't use git bisect
> run to drive the bisection. I don't think git bisect bad/good is
> returning a different status code when the first bad commit is found
> and this would be very useful to stop the driver of the bisection
Hi
I'm using git bisect, and for complex reasons I can't use git bisect
run to drive the bisection. I don't think git bisect bad/good is
returning a different status code when the first bad commit is found
and this would be very useful to stop the driver of the bisection.
What do you think? Woul
9 matches
Mail list logo
