Antoine Delaite writes:
>>> +get_terms () {
>>> +if test -s "$GIT_DIR/BISECT_TERMS"
>>> +then
>>> +NAME_BAD="$(sed -n 1p "$GIT_DIR/BISECT_TERMS")"
>>> +NAME_GOOD="$(sed -n 2p "$GIT_DIR/BISECT_TERMS")"
>>
>>It is sad that we need to open the file twi
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> But I do not think it is a good idea to penalize the normal case by
>> writing the terms file and reading them back from it when the user
>> is bisecting with good/bad in the first place, so
>
> No strong opinion on that, but creating one fi
Louis-Alexandre Stuber writes:
> But ENOENT is not a normal case at all. Should we not treat it the same
> way as other fopen() errors ? (either going on with default case or
> returning an error)
>
> Would :
>
>> if (!fp) {
>> die("could not read file '%s': %s",
>>
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Louis-Alexandre Stuber writes:
>>
That is very different from ENOENT, which is an expected error when
you are not using a customized terms.
>>>
>>> But in the current state, we are going to create bisect_terms even if
>>> the bisectio
Matthieu Moy writes:
> Louis-Alexandre Stuber writes:
>
>>> That is very different from ENOENT, which is an expected error when
>>> you are not using a customized terms.
>>
>> But in the current state, we are going to create bisect_terms even if
>> the bisection is in bad/good mode.
>
> Which me
But ENOENT is not a normal case at all. Should we not treat it the same
way as other fopen() errors ? (either going on with default case or
returning an error)
Would :
> if (!fp) {
> die("could not read file '%s': %s",
> filename, strerror
Louis-Alexandre Stuber writes:
>> That is very different from ENOENT, which is an expected error when
>> you are not using a customized terms.
>
> But in the current state, we are going to create bisect_terms even if
> the bisection is in bad/good mode.
Which means that in normal cases, you'll e
> That is very different from ENOENT, which is an expected error when
> you are not using a customized terms.
But in the current state, we are going to create bisect_terms even if
the bisection is in bad/good mode. Should we differentiate the erors
then ? and should we abort the bisection instead
Louis-Alexandre Stuber writes:
> Matthieu Moy wrote:
>
>> I think you would want to error out if errno is not ENOENT.
>
>
> Junio C Hamano wrote:
>
>> We might want to see why fopen() failed here. If it is because the
>> file did not exist, great. But otherwise?
>
>
> This file is always suppos
Matthieu Moy wrote:
> I think you would want to error out if errno is not ENOENT.
Junio C Hamano wrote:
> We might want to see why fopen() failed here. If it is because the
> file did not exist, great. But otherwise?
This file is always supposed to exist when the function is called
unless t
Hi,
Thanks for the review,
Junio C Hamano writes:
>> /*
>> + * The terms used for this bisect session are stocked in
>> + * BISECT_TERMS: it can be bad/good or new/old.
>> + * We read them and stock them to adapt the messages
>> + * accordingly. Default is bad/good.
>> + */
>
>s/stock/store/ p
On Tue, Jun 9, 2015 at 9:01 AM, Matthieu Moy
wrote:
>> Subject: Re: [PATCH 3/4] bisect: simplify the add of new bisect terms
>
> s/add/addition/
>
> Antoine Delaite writes:
>
>> +static const char *name_bad;
>> +static const char *name_good;
>
> Same rema
> Subject: Re: [PATCH 3/4] bisect: simplify the add of new bisect terms
s/add/addition/
Antoine Delaite writes:
> +static const char *name_bad;
> +static const char *name_good;
Same remark as PATCH 2.
> } else if (starts_with(refname, "good-")) {
D
Antoine Delaite writes:
> We create a file BISECT_TERMS in the repository .git to be read during a
> bisection. The fonctions to be changed if we add new terms are quite
> few.
> In git-bisect.sh :
> check_and_set_terms
> bisect_voc
> In bisect.c :
> handle_bad_merge_base
>
> Si
14 matches
Mail list logo
