Any news about this patch?
2017-03-21 22:24 GMT+01:00 Alex Hoffman :
> Hi, Brian,
>
> We definitely prefer the wrapper function oid_to_hex() to
> sha1_to_hex(). Thanks for feedback.
> Below is the updated patch:
>
> ---
> bisect.c | 6 +++---
> 1 file changed, 3
Hi, Brian,
We definitely prefer the wrapper function oid_to_hex() to
sha1_to_hex(). Thanks for feedback.
Below is the updated patch:
---
bisect.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/bisect.c b/bisect.c
index 30808cadf..7b65acbcd 100644
--- a/bisect.c
+++ b/b
---
bisect.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/bisect.c b/bisect.c
index 30808cadf..6feed8533 100644
--- a/bisect.c
+++ b/bisect.c
@@ -131,7 +131,7 @@ static void show_list(const char *debug, int
counted, int nr,
unsigned flags = commit->obje
> 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
> 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
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
> 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
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
> 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
ood and v.bad, instead of all paths (in my
example graph there are two such paths). I will also underline that
git bisect was designed to work with multiple good commits and one bad
commit (also multiple paths), but probably NOT with multiple paths
between the same pair of good and bad commits.
VG
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-
12 matches
Mail list logo
