Jeff King writes:
> Yeah, I really would have expected this to work, too. Should we be
> taking the merge base of the set of "new" commits, and using that as the
> true "new"?
> ...
> So maybe that's not workable.
>
> (I've never really dug into the bisect algorithm, and this is written
> largely
On Wed, Nov 22, 2017 at 05:01:29PM +, Adam Dinwoodie wrote:
> > So if you test a commit that git bisect asks you to test, and it
> > appears that this commit is "new", then you can just discard the
> > previous "new" commit because it will give you less information than
> > the new "new" one.
On Wednesday 22 November 2017 at 05:21 pm +0100, Christian Couder wrote:
> On Wed, Nov 22, 2017 at 3:39 PM, Adam Dinwoodie wrote:
> > In trying to do a bisect on the Git repository, I seem to have come
> > across surprising behavior where the order in which `git bisect` appears
> > to forget that
On Wed, Nov 22, 2017 at 3:39 PM, Adam Dinwoodie wrote:
> In trying to do a bisect on the Git repository, I seem to have come
> across surprising behavior where the order in which `git bisect` appears
> to forget that previous commits were marked as new.
Yeah, the algorithm uses many "old" commits
In trying to do a bisect on the Git repository, I seem to have come
across surprising behavior where the order in which `git bisect` appears
to forget that previous commits were marked as new.
You can see this behaviour in the following commands, run on the Git
repository, where the order of the `
5 matches
Mail list logo
