Antoine Delaite writes:
>>> -
>>> - fprintf(stderr, "The merge base %s is bad.\n"
>>> - "This means the bug has been fixed "
>>> - "between %s and [%s].\n",
>>> - bad_hex, bad_hex, good_hex);
>>> -
>>> + if (!strcmp(name_bad, "bad")) {
>>> + fprintf(stderr, "The merge base %s is bad.\n"
Matthieu Moy writes:
> Antoine Delaite writes:
>
>> --- a/git-bisect.sh
>> +++ b/git-bisect.sh
>> @@ -32,6 +32,8 @@ OPTIONS_SPEC=
>>
>> _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
>> _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
>> +NAME_BAD="bad"
>> +NAME_GOOD="good"
>
> I would have
Christian Couder writes:
> "old/new" is not more generic than "good/bad".
I disagree with this. In any case, we're looking for a pair of commits
where one is a direct parent of the other. So in the end, there's always
the old behavior and the new behavior in the end.
In natural language, I can
On Tue, Jun 9, 2015 at 8:45 AM, Matthieu Moy
wrote:
> Antoine Delaite writes:
>
>> --- a/git-bisect.sh
>> +++ b/git-bisect.sh
>> @@ -32,6 +32,8 @@ OPTIONS_SPEC=
>>
>> _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
>> _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
>> +NAME_BAD="bad"
>> +NAME_G
Antoine Delaite writes:
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -32,6 +32,8 @@ OPTIONS_SPEC=
>
> _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
> _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
> +NAME_BAD="bad"
> +NAME_GOOD="good"
I would have written
NAME_NEW=bad
NAME_OLD=good
Antoine Delaite writes:
> + *,"$NAME_BAD")
> + die "$(gettext "'git bisect $NAME_BAD' can take only one
> argument.")" ;;
H, doesn't this break i18n the big way?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kern
6 matches
Mail list logo
