[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pr

From: Harald Hanche-Olsen
Subject: Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt
Date: Mon, 06 Apr 2015 18:54:51 +0200
User-agent: Postbox 3.0.11 (Macintosh/20140602)

Artur Malabarba wrote:
git bisect searches the history of a single branch, and the history of
each branch is linear.

When you create other branches that doesn't affect the history of the
parent branch. And when you merge another branch onto the current one,
all it does is add a bunch of commits to it (which is linear).

I don't understand. Say someone creates a branch foo from master. Then each branch has several commits, and foo is merged into master. How do you linearly order the commits that happened on the separate branches?

As far as I understand the bisection method, it relies on a linear order with this property: You are looking for a bug which was introduced at an unknown commit B, and you need to be assured that the bug will be absent in commit X if, and only if, X is before B in the linear order used. I don't see how you can define such a linear order in the above scenario. (We're assuming that the bug is present in X if and only if X is either equal to B or a descendant of B.)

– Harald

reply via email to

[Prev in Thread] Current Thread [Next in Thread]