> Anyway, I don't think it is feasible to weaken the assumption that there
> is only one transition from 'old' ('good') to 'new' ('bad'); this is
> what allows O(log(N)) operations. See bisection method of root finding,
> that is finding zeros of a continuous function.
I don't intended to change
>>> Then you must adjust your definition of "good": All commits that do not have
>>> the feature, yet, are "good": since they do not have the feature in the
>>> first place, they cannot have the breakage that you found in the feature.
>>>
>>> That is exactly the situation in your original example!
. Would be nice to have a kind of
'Getting Started Manual'
Thanks for your time,
Oleg Taranenko
Sorry for bothering, why not introduce a brand new option like git
checkout -b foo --skip-worktree-merge for such rare optimization use
case?
On Wed, Sep 14, 2016 at 12:34 AM, Junio C Hamano wrote:
> Ben Peart writes:
>
>> +static int needs_working_tree_merge(const struct checkout_opts *opts,
>>
On Tue, Aug 2, 2016 at 11:00 PM, Junio C Hamano wrote:
> Oleg Taranenko writes:
>
>> First, assuming the common ancestor is GOOD based on the fact that
>> some descendant given as GOOD is pretty bad idea.
>
> What you claim is fundamentally incompatible with the way "
Guys,
thanks for discussion, I will try to reply in bulk here.
First, assuming the common ancestor is GOOD based on the fact that
some descendant given as GOOD is pretty bad idea.
It may be, but may not be. In the git-flow like workflows new features
(aka branches) are created from trunk (master/d
t bisect bad
Bisecting: 2 revisions left to test after this (roughly 1 step)
[e571fdd09582e40fc54ffc5a4f112eac2b9f2c8e] prepare cocktail
git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[041a5a53704bccc60c489f8c9a4742bad79d5a95] tee
git bisect bad
041a5a53704bccc60c
uot;sugar"
git bisect start
git bisect good
git bisect bad develop # 23a4
cat coffee # nothing
git bisect bad # c080
cat coffee # nothing
git bisect bad #
c080fb4df39d721e2f2e0fdd91fe16d8bdd77515 is the first bad commit
commit c080fb4df39d721e2f2e
Hi all,
I just found an interesting post how git bisect can trouble humans.
Full story is here
https://groups.google.com/forum/#!topic/git-users/v3__t42qbKE
My suggestion to fix it (ditto)
What I suggest change logic of bisecting to something like
git config bisect.reachable true
Th
9 matches
Mail list logo
