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 "bisect"
> works as a O(log(n)
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 "bisect"
works as a O(log(n)) operation. It is likely that your definition
of Good for the pu
On Tue, Aug 2, 2016 at 3:15 AM, Oleg Taranenko wrote:
> 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 work
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
Christian Couder writes:
>> I think the "previous issue" was that we can ask the user to ask to
>> check one of 'x' or 'y' when given Good and Bad points in a graph like
>> this:
>>
>> x---y---y---o---B
>> \ /
>> x---G---o
>>
>> while a more natural expectation
On Mon, Aug 1, 2016 at 9:51 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> Yes, and the reason is that all the ancestors of a good commit are
>> considered good.
>> That's because git bisect supposes that there is only one transition
>> from good to bad.
>> Otherwise we would need a mo
Christian Couder writes:
> Yes, and the reason is that all the ancestors of a good commit are
> considered good.
> That's because git bisect supposes that there is only one transition
> from good to bad.
> Otherwise we would need a more complex algorithm to find all the
> transitions from good to
On Mon, Aug 1, 2016 at 12:02 PM, Oleg Taranenko wrote:
> Guys,
>
> further investigation shows, git bisect is broken from its core... really.
> Let consider 3rd a bit more complicated scenario
>
> #cd ..
> #rm -rf bisect3
> mkdir bisect3
> cd bisect3
> git init
> git touch coffee
git touch is not
Jakub Narębski writes:
> Isn't `--reachable-commits` the same as existing `--ancestry-path`
> option to `git log` and friends (I wonder if passing log options to
> bisect, that is: `git bisect --ancestry-path ...` would work)?
Yes, I somehow missed it, but you are absolutely correct to point
out
Guys,
further investigation shows, git bisect is broken from its core... really.
Let consider 3rd a bit more complicated scenario
#cd ..
#rm -rf bisect3
mkdir bisect3
cd bisect3
git init
git touch coffee
git commit -am "create coffee"
git branch tee
echo sugar >> coffee
git commit -am "add sugar"
W dniu 31.07.2016 o 02:06, Oleg Taranenko pisze:
> Then, I suggest as well additional to defaulting via 'git config
> bisect.reachable true/false' use per bisect session switch
>
> git bisect start --[un-]reachable-commits # which will override
> default setting
Isn't `--reachable-commits` t
Hi Junio,
Thanks for reply.
Let consider two pretty similar use cases.
SCENARIO 1
mkdir bisect
cd bisect/
git init
git touch coffee
git commit -am "create coffee"
git branch develop
echo sugar >> coffee
git commit -am "add sugar" # we are still in master branch
git chec
Oleg Taranenko writes:
> What I suggest change logic of bisecting to something like
>
> git config bisect.reachable true
Such a configuration should not be needed.
When a history with this shape is given to "git bisect":
o---o---X---Y---B
\ /
o---G
and you
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
14 matches
Mail list logo
