Antoine Delaite writes:
> Matthieu Moy writes:
>
>>>
# terms_defined is 0 when the user did not define the terms explicitely
# yet. This is the case when running 'git bisect start bad_rev good_rev'
# before we see an explicit reference to a term.
terms_defined=0
>>>
>>> Th
Matthieu Moy writes:
>>
>>># terms_defined is 0 when the user did not define the terms explicitely
>>># yet. This is the case when running 'git bisect start bad_rev good_rev'
>>># before we see an explicit reference to a term.
>>>terms_defined=0
>>
>> The thing is:
>> 'git bisect reset
>
Antoine Delaite writes:
> Matthieu Moy writes:
>
>># terms_defined is 0 when the user did not define the terms explicitely
>># yet. This is the case when running 'git bisect start bad_rev good_rev'
>># before we see an explicit reference to a term.
>>terms_defined=0
>
> The thing is:
> 'git bise
Matthieu Moy writes:
># terms_defined is 0 when the user did not define the terms explicitely
># yet. This is the case when running 'git bisect start bad_rev good_rev'
># before we see an explicit reference to a term.
>terms_defined=0
The thing is:
'git bisect reset
git bisect new HEAD
(autostar
Matthieu Moy writes:
>I would say "for the current bisection", i.e.
>
>$ git bisect start
>$ git bisect terms foo bar # Scope starts here
>...
>The first 'bar' commit is deadbeef. # Scope ends here
>
>$ git bisect terms foo bar
>You need to start by "git bisect start"
>Do you want me to
Matthieu Moy writes:
> I would say terms_defined is OK even if only the first patches get
> merged. The reason why you need this variable is because you need to
> know whether the terms have been defined or not, and to me that's the
> most important.
Well said. Thanks.
>
> I'd suggest somethin
Antoine Delaite writes:
> To submit a v3 I would need answer about how we rebase the commit
> history and what do we do to simplify the life of the user with the
> terms (see my last mails).
> I was thinking of:
> -a config variable that would say :"as long as I don't reset keep
> the terms
Antoine Delaite writes:
> Matthieu Moy writes:
>
>>> +if test -s "$GIT_DIR/TERMS_DEFINED"
>>> +then
>>> +terms_defined=1
>>> +get_terms
>>> +rm -rf "$GIT_DIR/TERMS_DEFINED"
>>
>>I don't understand why you need to delete this file. I
Antoine Delaite writes:
> Louis Stuber writes:
>
>>Matthieu Moy writes:
>>
>>> Modifying in PATCH 7 some code that you introduced in PATCH 3 is
>>> suspicious. Is there any reason you did not name the variable
>>> "terms_defined" in the first place? (i.e. squash this hunk and the other
>>
This message's goal is to explained where am I on the bisect
functions.
-git bisect replay now work with any terms.
-I took account of most of the last reviews (coding style,
double sed ...)
-'git bisect terms' without arguments now display the current
terms
-bisect_terms : if a bisection ha
Matthieu Moy writes:
>> +if test -s "$GIT_DIR/TERMS_DEFINED"
>> +then
>> +terms_defined=1
>> +get_terms
>> +rm -rf "$GIT_DIR/TERMS_DEFINED"
>
>I don't understand why you need to delete this file. I did not review
>thoroughly so there
Louis Stuber writes:
>Matthieu Moy writes:
>
>> Modifying in PATCH 7 some code that you introduced in PATCH 3 is
>> suspicious. Is there any reason you did not name the variable
>> "terms_defined" in the first place? (i.e. squash this hunk and the other
>> instance of start_bad_good into P
Matthieu Moy writes:
> Modifying in PATCH 7 some code that you introduced in PATCH 3 is
> suspicious. Is there any reason you did not name the variable
> "terms_defined" in the first place? (i.e. squash this hunk and the other
> instance of start_bad_good into PATCH 3)
>
> (Whether this is a reth
Antoine Delaite writes:
> - # start_bad_good is used to detect if we did a
> - # 'git bisect start bad_rev good_rev'
> - start_bad_good=0
> + # terms_defined is used to detect if we did a
> + # 'git bisect start bad_rev good_rev' or if the user
> + # defined his own terms
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Junio C Hamano writes:
>>
>>> +bisect_terms () {
>>> + test $# -eq 2 ||
>>> + die "You need to give me at least two arguments"
>>> +
>>> + if ! test -s "$GIT_DIR/BISECT_START"
>>> + then
>>> + echo $1 >"$GIT_DIR/BISECT_TERMS"
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Antoine Delaite writes:
>>
>>> -USAGE='[help|start|bad|good|new|old|skip|next|reset|visualize|replay|log|run]'
>>> +USAGE='[help|start|bad|good|new|old|terms|skip|next|reset|visualize|replay|log|run]'
>>
>> I think this patch makes the whole se
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> +bisect_terms () {
>> +test $# -eq 2 ||
>> +die "You need to give me at least two arguments"
>> +
>> +if ! test -s "$GIT_DIR/BISECT_START"
>> +then
>> +echo $1 >"$GIT_DIR/BISECT_TERMS" &&
>> +echo $2 >>"
Junio C Hamano writes:
> Antoine Delaite writes:
>
>> -USAGE='[help|start|bad|good|new|old|skip|next|reset|visualize|replay|log|run]'
>> +USAGE='[help|start|bad|good|new|old|terms|skip|next|reset|visualize|replay|log|run]'
>
> I think this patch makes the whole series go in the right direction.
Junio C Hamano writes:
> I like this change very much; it removes the mysteriously misnamed
> start-bad-good variable (because you do not really _care_ that
> 'start' was what implicitly decided that good/bad pair is the term
> we use in this session; what you care is that the terms are already
>
Antoine Delaite writes:
> -USAGE='[help|start|bad|good|new|old|skip|next|reset|visualize|replay|log|run]'
> +USAGE='[help|start|bad|good|new|old|terms|skip|next|reset|visualize|replay|log|run]'
I think this patch makes the whole series go in the right direction.
I wonder if you can skip the "we
Introduction of the git bisect terms function.
The user can set its own terms.
List of known commands not available :
`git bisect replay`
`git bisect terms term1 term2
then
git bisect start bad_rev good_rev`
Signed-off-by: Antoine Delaite
Signed-off-by: Louis Stuber
---
Documentation/git-bisec
21 matches
Mail list logo
