Michael Haggerty writes:
> It seems to me that we can infer which mark is which from the normal
> bisect user interaction. At the startup phase of a bisect, there are
> only three cases:
>
> 1. There are fewer than two different types of marks on tested commits.
>For example, maybe one commi
On 03/12/2014 07:31 PM, Junio C Hamano wrote:
> Jacopo Notarstefano writes:
>
>> On Mon, Mar 3, 2014 at 7:34 PM, Junio C Hamano wrote:
>>> I think you fundamentally cannot use two labels that are merely
>>> "distinct" and bisect correctly. You need to know which ones
>>> (i.e. good) are to be e
Jacopo Notarstefano writes:
> On Mon, Mar 3, 2014 at 7:34 PM, Junio C Hamano wrote:
>> I think you fundamentally cannot use two labels that are merely
>> "distinct" and bisect correctly. You need to know which ones
>> (i.e. good) are to be excluded and the other (i.e. bad) are to be
>> included
On Mon, Mar 3, 2014 at 7:34 PM, Junio C Hamano wrote:
> I think you fundamentally cannot use two labels that are merely
> "distinct" and bisect correctly. You need to know which ones
> (i.e. good) are to be excluded and the other (i.e. bad) are to be
> included when computing the "remaining to be
Jacopo Notarstefano writes:
> Here my proposal differs in that I have no way of knowing which label
> is good and which label is bad: I blindly accept two distinct labels
> and bisect with those. I gave an example of this behaviour above.
I think you fundamentally cannot use two labels that are
> I am not sure I understand what you are trying to say. Are you
> saying that we should stick to good/bad and allow the users use
> nothing else, because allowing "fixed" will be confusing?
>
No! Pretty much the opposite of that. My idea (the "mark" subcommand)
is to let people define their own
Jacopo Notarstefano writes:
> On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty
> wrote:
>> I don't understand the benefit of adding a new command "mark" rather
>> than continuing to use "good", "bad", plus new commands "unfixed" and
>> "fixed". Does this solve any problems?
>>
>
> As Matthie
> - git could emit an error message and refuse to continue
> - git could interpret the command one way or the other, with or without a
> warning
>
> By my count that gives at least five possibilities. The feature cannot be
> implemented without choosing one.
>
Let me explain what I meant with an
This email was sent privately by Michael to me as a result of my
previous error. I'm quoting it in its entirety so that he doesn't have
to submit it twice.
On Thu, Feb 27, 2014 at 8:32 PM, Michael Haggerty wrote:
> Please forgive my typos and brevity; this was typed on a phone.
>
> Michael
> On F
On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty wrote:
> I don't understand the benefit of adding a new command "mark" rather
> than continuing to use "good", "bad", plus new commands "unfixed" and
> "fixed". Does this solve any problems?
>
As Matthieu Moy remarked in a previous email, the ma
Mh. Haven't thought of that. I have no experience with TK, so I'm
having trouble digging up where the "good" and "bad" labels in the GUI
are generated.
I guess that a solution might involve writing a temporary file in
$GIT_DIR called something like BISECT_LABELS in which the chosen
labels are list
On 27 February 2014 06:47, Christian Couder wrote:
> But I think the most important thing right now is first to gather as
> much information as you can from the previous discussions on this
> topic on this mainling list.
> Perhaps you should also gather information on how git bisect works.
I have
Hi,
On Wed, Feb 26, 2014 at 9:28 AM, Jacopo Notarstefano
wrote:
> Hey everyone,
>
> my name is Jacopo, a student developer from Italy, and I'm interested
> in applying to this years' Google Summer of Code. I set my eyes on the
> project called "git-bisect improvements", in particular the subtask
- Original Message -
> I don't understand the benefit of adding a new command "mark" rather
> than continuing to use "good", "bad", plus new commands "unfixed" and
> "fixed". Does this solve any problems?
I think it could be interesting to allow arbitrary words here. For example, I
recen
On 02/26/2014 09:28 AM, Jacopo Notarstefano wrote:
> my name is Jacopo, a student developer from Italy, and I'm interested
> in applying to this years' Google Summer of Code. I set my eyes on the
> project called "git-bisect improvements", in particular the subtask
> about swapping the "good" and "
Jacopo Notarstefano writes:
> Does this make sense? Did I overlook some details?
How does this solve the labels shown in "git bisect visualize"?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:/
Hey everyone,
my name is Jacopo, a student developer from Italy, and I'm interested
in applying to this years' Google Summer of Code. I set my eyes on the
project called "git-bisect improvements", in particular the subtask
about swapping the "good" and "bad" labels when looking for a
bug-fixing re
17 matches
Mail list logo
