From: "Alex Hoffman"
isn't that spelt `--ancestry-path` ?
(--ancestry-path has it's own issues such as needing
an --first-parent-show
option, but that's possibly a by the by)
Indeed it is spelled `--ancestry-path`. And interestingly enough you
may use it multiple times with the wanted effect
> isn't that spelt `--ancestry-path` ?
> (--ancestry-path has it's own issues such as needing an --first-parent-show
> option, but that's possibly a by the by)
Indeed it is spelled `--ancestry-path`. And interestingly enough you
may use it multiple times with the wanted effect in our case (e.g whe
From: "Jakub Narębski"
W dniu 20.02.2017 o 21:31, Alex Hoffman pisze:
I see two different problems each with a different assumption (see the
definition of "bisectable" in the email of Junio C Hamano):
1. (Current) Assume the entire history graph is bisectable. DO: Search
where in the entire gr
> If `git bisect` is/would be affected by `git log` history-related options
> then this is what `--strict-ancestor` option gives/would give.
Exactly my thoughts. All that needs to be changed in the 2nd problem
is the graph where to search.
But first we must agree about the usefulness of the 2nd p
W dniu 20.02.2017 o 21:31, Alex Hoffman pisze:
> I see two different problems each with a different assumption (see the
> definition of "bisectable" in the email of Junio C Hamano):
>
> 1. (Current) Assume the entire history graph is bisectable. DO: Search
> where in the entire graph the first 'tr
I see two different problems each with a different assumption (see the
definition of "bisectable" in the email of Junio C Hamano):
1. (Current) Assume the entire history graph is bisectable. DO: Search
where in the entire graph the first 'trait'/transition occurs.
2. (New) Assume only the graph be
> 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
W dniu 20.02.2017 o 08:38, Oleg Taranenko pisze:
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.
Christian Couder writes:
> git bisect makes some assumptions that are true most of the time, so
> in practice it works well most of the time.
I think we need to clarify the documentation and ask you to stop
using such fuzzy phrases like "assumptions" and "most of the time"
;-).
For bisection to
>>> 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!
On Sun, Feb 19, 2017 at 11:05 AM, Alex Hoffman wrote:
>> 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 i
> 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! But you co
Am 19.02.2017 um 12:32 schrieb Alex Hoffman:
The assumption that there is no transition from bad to good in the
graph did not hold in my example and it does not hold when a feature
was recently introduced and gets broken relative shortly afterwards.
Then you must adjust your definition of "good
On Sun, Feb 19, 2017 at 12:32 PM, Alex Hoffman wrote:
>> At the end of the git-bisect man page (in the SEE ALSO section) there
>> is a link to
>> https://github.com/git/git/blob/master/Documentation/git-bisect-lk2009.txt
>> which has a lot of details about how bisect works.
>
> Thanks for pointin
Below is a correction of the first proposed algorithm:
>--o1--o2--o3--G --X1
>\\
> x1--x2--x3--x4--X2--B--
> \ /
> y1--y2--y3
>
Step 1a. (Unchanged) keep only the commits that:
a) are ancestor of the "bad" commit (including the "bad" commit
> At the end of the git-bisect man page (in the SEE ALSO section) there
> is a link to
> https://github.com/git/git/blob/master/Documentation/git-bisect-lk2009.txt
> which has a lot of details about how bisect works.
>
Thanks for pointing out the SEE ALSO section. I think it makes sense
to includ
Am 18.02.2017 um 19:36 schrieb Alex Hoffman:
Let's consider your example with distinct names for nodes:
--o1--o2--o3--G--X1
\\
x1--x2--x3--x4--X2--B--
It makes sense that git bisect is expecting a single transition, as
this is a precondition for a binary search to work.
On 18 February 2017 at 10:36, Alex Hoffman wrote:
> You definitely convinced me that git MUST search more than only in the
> paths between good and bad commits, as the good commit G does not have
> to be the first good commit (thank you for that). My problem/confusion
> is that it returns somethin
From: "Alex Hoffman"
But this is not how Git works. Git computes graph differences, i.e., it
subtracts from the commits reachable from v.bad those that are reachable
from v.good. This leaves more than just those on some path from v.good to
v.bad. And it should work this way. Consider this histor
On Sat, Feb 18, 2017 at 7:36 PM, Alex Hoffman wrote:
>> But this is not how Git works. Git computes graph differences, i.e., it
>> subtracts from the commits reachable from v.bad those that are reachable
>> from v.good. This leaves more than just those on some path from v.good to
>> v.bad. And it
> But this is not how Git works. Git computes graph differences, i.e., it
> subtracts from the commits reachable from v.bad those that are reachable
> from v.good. This leaves more than just those on some path from v.good to
> v.bad. And it should work this way. Consider this history:
>
> --o--o--o
Am 18.02.2017 um 12:15 schrieb Alex Hoffman:
No one commented the fact, that I find this very confusing. Don't you
find this confusing? I will underline, that 'git bisect good v.good'
will fail if the commit 'v.good' is not a parent of the bad commit,
meaning there MUST be at least a path between
>> First of all this is confusing, as this commit cannot be reached
>> starting from "v.good".
> Hm, IMHO it shows that your example is pretty artificial (although you
> might have come across it in a real-world scenario): you introduced a
> new feature in f4154e9 (and it worked) and you broke tha
Am 18.02.2017 um 00:21 schrieb Stephan Beyer:
On 02/17/2017 11:29 PM, Alex Hoffman wrote:
* 7a9e952 (bisect bad)
|\
| * 671cec2 <--- expected
| |\
| * | 04c6f4b <--- found
* | | 3915157
|\ \ \
| | |/
| |/|
| * | f4154e9 (bisect good)
| * | 85855bf
| |/
* | f1a36f5
|/
* 1b7fb88
The
Hi,
On 02/17/2017 11:29 PM, Alex Hoffman wrote:
> According to the documentation "git bisect" is designed "to find the
> commit that introduced a bug" .
> I have found a situation in which it does not returns the commit I expected.
> In order to reproduce the problem:
For the others who are too l
Hi there,
According to the documentation "git bisect" is designed "to find the
commit that introduced a bug" .
I have found a situation in which it does not returns the commit I expected.
In order to reproduce the problem:
1. mkdir test; cd test;
git clone https://github.com/entbugger/git-bisect-
26 matches
Mail list logo
