Re: git bisect for reachable commits only

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

Re: git bisect for reachable commits only

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

Re: git bisect for reachable commits only

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.

Re: git bisect for reachable commits only

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

Re: git bisect for reachable commits only

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 >> >>

Re: git bisect for reachable commits only

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 >>

Re: git bisect for reachable commits only

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

Re: git bisect for reachable commits only

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

Re: git bisect for reachable commits only

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

Re: git bisect for reachable commits only

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

Re: git bisect for reachable commits only

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`

Re: git bisect for reachable commits only

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

Re: git bisect for reachable commits only

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 \

git bisect for reachable commits only

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