git/bisect.c

1188 lines
30 KiB
C
Raw Normal View History

#include "cache.h"
#include "config.h"
#include "commit.h"
#include "diff.h"
#include "revision.h"
#include "refs.h"
#include "list-objects.h"
#include "quote.h"
#include "hash-lookup.h"
#include "run-command.h"
#include "log-tree.h"
#include "bisect.h"
#include "oid-array.h"
#include "strvec.h"
#include "commit-slab.h"
#include "commit-reach.h"
#include "object-store.h"
#include "dir.h"
static struct oid_array good_revs;
static struct oid_array skipped_revs;
static struct object_id *current_bad_oid;
static const char *argv_checkout[] = {"checkout", "-q", NULL, "--", NULL};
static const char *term_bad;
static const char *term_good;
/* Remember to update object flag allocation in object.h */
#define COUNTED (1u<<16)
/*
* This is a truly stupid algorithm, but it's only
* used for bisection, and we just don't care enough.
*
* We care just barely enough to avoid recursing for
* non-merge entries.
*/
static int count_distance(struct commit_list *entry)
{
int nr = 0;
while (entry) {
struct commit *commit = entry->item;
struct commit_list *p;
if (commit->object.flags & (UNINTERESTING | COUNTED))
break;
if (!(commit->object.flags & TREESAME))
nr++;
commit->object.flags |= COUNTED;
p = commit->parents;
entry = p;
if (p) {
p = p->next;
while (p) {
nr += count_distance(p);
p = p->next;
}
}
}
return nr;
}
static void clear_distance(struct commit_list *list)
{
while (list) {
struct commit *commit = list->item;
commit->object.flags &= ~COUNTED;
list = list->next;
}
}
define_commit_slab(commit_weight, int *);
static struct commit_weight commit_weight;
#define DEBUG_BISECT 0
static inline int weight(struct commit_list *elem)
{
return **commit_weight_at(&commit_weight, elem->item);
}
static inline void weight_set(struct commit_list *elem, int weight)
{
**commit_weight_at(&commit_weight, elem->item) = weight;
}
static int count_interesting_parents(struct commit *commit, unsigned bisect_flags)
{
struct commit_list *p;
int count;
for (count = 0, p = commit->parents; p; p = p->next) {
if (!(p->item->object.flags & UNINTERESTING))
count++;
if (bisect_flags & FIND_BISECTION_FIRST_PARENT_ONLY)
break;
}
return count;
}
bisect: loosen halfway() check for a large number of commits 'git bisect start ...' and subsequent 'git bisect (good|bad)' commands can take quite a while when the given/remaining revision range between good and bad commits is big and contains a lot of merge commits, e.g. in git.git: $ git rev-list --count v1.6.0..v2.28.0 44284 $ time git bisect start v2.28.0 v1.6.0 Bisecting: 22141 revisions left to test after this (roughly 15 steps) [e197c21807dacadc8305250baa0b9228819189d4] unable_to_lock_die(): rename function from unable_to_lock_index_die() real 0m15.472s user 0m15.220s sys 0m0.255s The majority of the runtime is spent in do_find_bisection(), where we try to find a commit as close as possible to the halfway point between the bad and good revisions, i.e. a commit from which the number of reachable commits that are in the good-bad range is half the total number of commits in that range. So we count how many commits are reachable in the good-bad range for each commit in that range, which is quick and easy for a linear history, even over 300k commits in a linear range are handled in ~0.3s on my machine. Alas, handling merge commits is non-trivial and quite expensive as the algorithm used seems to be quadratic, causing the long runtime shown above. Interestingly, look at what a big difference one additional commit can make: $ git rev-list --count v1.6.0^..v2.28.0 44285 $ time git bisect start v2.28.0 v1.6.0^ Bisecting: 22142 revisions left to test after this (roughly 15 steps) [565301e41670825ceedf75220f2918ae76831240] Sync with 2.1.2 real 0m5.848s user 0m5.600s sys 0m0.252s The difference is caused by one of the optimizations attempting to cut down the runtime added in 1c4fea3a40 (git-rev-list --bisect: optimization, 2007-03-21): Another small optimization is whenever we find a half-way commit (that is, a commit that can reach exactly half of the commits), we stop giving counts to remaining commits, as we will not find any better commit than we just found. In this second 'git bisect start' command we happen to find a commit exactly at the halfway point and can return early, but in the first case there is no such commit, so we can't return early and end up counting the number of reachable commits from all commits in the good-bad range. However, when we have thousands of commits it's not all that important to find the _exact_ halfway point, a few commits more or less doesn't make any real difference for the bisection. So let's loosen the check in the halfway() helper to consider commits within about 0.1% of the exact halfway point as halfway as well, and rename the function to approx_halfway() accordingly. This will allow us to return early on a bigger good-bad range, even when there is no commit exactly at the halfway point, thereby reducing the runtime of the first command above considerably, from ~15s to 4.901s. Furthermore, even if there is a commit exactly at the halfway point, we might still stumble upon a commit within that 0.1% range before finding the exact halfway point, allowing us to return a bit earlier, slightly reducing the runtime of the second command from 5.848s to 5.058s. Note that this change doesn't affect good-bad ranges containing ~2000 commits or less, because that 0.1% tolerance becomes zero due to integer arithmetic; however, if the range is that small then counting the reachable commits for all commits is already fast enough anyway. Naturally, this will likely change which commits get picked at each bisection step, and, in turn, might change how many bisection steps are necessary to find the first bad commit. If the number of necessary bisection steps were to increase often, then this change could backfire, because building and testing at each step might take much longer than the time spared. OTOH, if the number of steps were to decrease, then it would be a double win. So I ran some tests to see how often that happens: picked random good and bad starting revisions at least 50k commits apart and a random first bad commit in between in git.git, and used 'git bisect run git merge-base --is-ancestor HEAD $first_bad_commit' to check the number of necessary bisection steps. After repeating all this 1000 times both with and without this patch I found that: - 146 cases needed one more bisection step than before, 149 cases needed one less step, while in the remaining 705 cases the number of steps didn't change. So the number of bisection steps does indeed change in a non-negligible number of cases, but it seems that the average number of steps doesn't change in the long run. - The first 'git bisect start' command got over 3x faster in 456 cases, so this "no commit at the exact halfway point" case seems to be common enough to care about. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-12 17:19:38 +01:00
static inline int approx_halfway(struct commit_list *p, int nr)
{
bisect: loosen halfway() check for a large number of commits 'git bisect start ...' and subsequent 'git bisect (good|bad)' commands can take quite a while when the given/remaining revision range between good and bad commits is big and contains a lot of merge commits, e.g. in git.git: $ git rev-list --count v1.6.0..v2.28.0 44284 $ time git bisect start v2.28.0 v1.6.0 Bisecting: 22141 revisions left to test after this (roughly 15 steps) [e197c21807dacadc8305250baa0b9228819189d4] unable_to_lock_die(): rename function from unable_to_lock_index_die() real 0m15.472s user 0m15.220s sys 0m0.255s The majority of the runtime is spent in do_find_bisection(), where we try to find a commit as close as possible to the halfway point between the bad and good revisions, i.e. a commit from which the number of reachable commits that are in the good-bad range is half the total number of commits in that range. So we count how many commits are reachable in the good-bad range for each commit in that range, which is quick and easy for a linear history, even over 300k commits in a linear range are handled in ~0.3s on my machine. Alas, handling merge commits is non-trivial and quite expensive as the algorithm used seems to be quadratic, causing the long runtime shown above. Interestingly, look at what a big difference one additional commit can make: $ git rev-list --count v1.6.0^..v2.28.0 44285 $ time git bisect start v2.28.0 v1.6.0^ Bisecting: 22142 revisions left to test after this (roughly 15 steps) [565301e41670825ceedf75220f2918ae76831240] Sync with 2.1.2 real 0m5.848s user 0m5.600s sys 0m0.252s The difference is caused by one of the optimizations attempting to cut down the runtime added in 1c4fea3a40 (git-rev-list --bisect: optimization, 2007-03-21): Another small optimization is whenever we find a half-way commit (that is, a commit that can reach exactly half of the commits), we stop giving counts to remaining commits, as we will not find any better commit than we just found. In this second 'git bisect start' command we happen to find a commit exactly at the halfway point and can return early, but in the first case there is no such commit, so we can't return early and end up counting the number of reachable commits from all commits in the good-bad range. However, when we have thousands of commits it's not all that important to find the _exact_ halfway point, a few commits more or less doesn't make any real difference for the bisection. So let's loosen the check in the halfway() helper to consider commits within about 0.1% of the exact halfway point as halfway as well, and rename the function to approx_halfway() accordingly. This will allow us to return early on a bigger good-bad range, even when there is no commit exactly at the halfway point, thereby reducing the runtime of the first command above considerably, from ~15s to 4.901s. Furthermore, even if there is a commit exactly at the halfway point, we might still stumble upon a commit within that 0.1% range before finding the exact halfway point, allowing us to return a bit earlier, slightly reducing the runtime of the second command from 5.848s to 5.058s. Note that this change doesn't affect good-bad ranges containing ~2000 commits or less, because that 0.1% tolerance becomes zero due to integer arithmetic; however, if the range is that small then counting the reachable commits for all commits is already fast enough anyway. Naturally, this will likely change which commits get picked at each bisection step, and, in turn, might change how many bisection steps are necessary to find the first bad commit. If the number of necessary bisection steps were to increase often, then this change could backfire, because building and testing at each step might take much longer than the time spared. OTOH, if the number of steps were to decrease, then it would be a double win. So I ran some tests to see how often that happens: picked random good and bad starting revisions at least 50k commits apart and a random first bad commit in between in git.git, and used 'git bisect run git merge-base --is-ancestor HEAD $first_bad_commit' to check the number of necessary bisection steps. After repeating all this 1000 times both with and without this patch I found that: - 146 cases needed one more bisection step than before, 149 cases needed one less step, while in the remaining 705 cases the number of steps didn't change. So the number of bisection steps does indeed change in a non-negligible number of cases, but it seems that the average number of steps doesn't change in the long run. - The first 'git bisect start' command got over 3x faster in 456 cases, so this "no commit at the exact halfway point" case seems to be common enough to care about. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-12 17:19:38 +01:00
int diff;
/*
* Don't short-cut something we are not going to return!
*/
if (p->item->object.flags & TREESAME)
return 0;
if (DEBUG_BISECT)
return 0;
/*
bisect: loosen halfway() check for a large number of commits 'git bisect start ...' and subsequent 'git bisect (good|bad)' commands can take quite a while when the given/remaining revision range between good and bad commits is big and contains a lot of merge commits, e.g. in git.git: $ git rev-list --count v1.6.0..v2.28.0 44284 $ time git bisect start v2.28.0 v1.6.0 Bisecting: 22141 revisions left to test after this (roughly 15 steps) [e197c21807dacadc8305250baa0b9228819189d4] unable_to_lock_die(): rename function from unable_to_lock_index_die() real 0m15.472s user 0m15.220s sys 0m0.255s The majority of the runtime is spent in do_find_bisection(), where we try to find a commit as close as possible to the halfway point between the bad and good revisions, i.e. a commit from which the number of reachable commits that are in the good-bad range is half the total number of commits in that range. So we count how many commits are reachable in the good-bad range for each commit in that range, which is quick and easy for a linear history, even over 300k commits in a linear range are handled in ~0.3s on my machine. Alas, handling merge commits is non-trivial and quite expensive as the algorithm used seems to be quadratic, causing the long runtime shown above. Interestingly, look at what a big difference one additional commit can make: $ git rev-list --count v1.6.0^..v2.28.0 44285 $ time git bisect start v2.28.0 v1.6.0^ Bisecting: 22142 revisions left to test after this (roughly 15 steps) [565301e41670825ceedf75220f2918ae76831240] Sync with 2.1.2 real 0m5.848s user 0m5.600s sys 0m0.252s The difference is caused by one of the optimizations attempting to cut down the runtime added in 1c4fea3a40 (git-rev-list --bisect: optimization, 2007-03-21): Another small optimization is whenever we find a half-way commit (that is, a commit that can reach exactly half of the commits), we stop giving counts to remaining commits, as we will not find any better commit than we just found. In this second 'git bisect start' command we happen to find a commit exactly at the halfway point and can return early, but in the first case there is no such commit, so we can't return early and end up counting the number of reachable commits from all commits in the good-bad range. However, when we have thousands of commits it's not all that important to find the _exact_ halfway point, a few commits more or less doesn't make any real difference for the bisection. So let's loosen the check in the halfway() helper to consider commits within about 0.1% of the exact halfway point as halfway as well, and rename the function to approx_halfway() accordingly. This will allow us to return early on a bigger good-bad range, even when there is no commit exactly at the halfway point, thereby reducing the runtime of the first command above considerably, from ~15s to 4.901s. Furthermore, even if there is a commit exactly at the halfway point, we might still stumble upon a commit within that 0.1% range before finding the exact halfway point, allowing us to return a bit earlier, slightly reducing the runtime of the second command from 5.848s to 5.058s. Note that this change doesn't affect good-bad ranges containing ~2000 commits or less, because that 0.1% tolerance becomes zero due to integer arithmetic; however, if the range is that small then counting the reachable commits for all commits is already fast enough anyway. Naturally, this will likely change which commits get picked at each bisection step, and, in turn, might change how many bisection steps are necessary to find the first bad commit. If the number of necessary bisection steps were to increase often, then this change could backfire, because building and testing at each step might take much longer than the time spared. OTOH, if the number of steps were to decrease, then it would be a double win. So I ran some tests to see how often that happens: picked random good and bad starting revisions at least 50k commits apart and a random first bad commit in between in git.git, and used 'git bisect run git merge-base --is-ancestor HEAD $first_bad_commit' to check the number of necessary bisection steps. After repeating all this 1000 times both with and without this patch I found that: - 146 cases needed one more bisection step than before, 149 cases needed one less step, while in the remaining 705 cases the number of steps didn't change. So the number of bisection steps does indeed change in a non-negligible number of cases, but it seems that the average number of steps doesn't change in the long run. - The first 'git bisect start' command got over 3x faster in 456 cases, so this "no commit at the exact halfway point" case seems to be common enough to care about. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-12 17:19:38 +01:00
* For small number of commits 2 and 3 are halfway of 5, and
* 3 is halfway of 6 but 2 and 4 are not.
*/
bisect: loosen halfway() check for a large number of commits 'git bisect start ...' and subsequent 'git bisect (good|bad)' commands can take quite a while when the given/remaining revision range between good and bad commits is big and contains a lot of merge commits, e.g. in git.git: $ git rev-list --count v1.6.0..v2.28.0 44284 $ time git bisect start v2.28.0 v1.6.0 Bisecting: 22141 revisions left to test after this (roughly 15 steps) [e197c21807dacadc8305250baa0b9228819189d4] unable_to_lock_die(): rename function from unable_to_lock_index_die() real 0m15.472s user 0m15.220s sys 0m0.255s The majority of the runtime is spent in do_find_bisection(), where we try to find a commit as close as possible to the halfway point between the bad and good revisions, i.e. a commit from which the number of reachable commits that are in the good-bad range is half the total number of commits in that range. So we count how many commits are reachable in the good-bad range for each commit in that range, which is quick and easy for a linear history, even over 300k commits in a linear range are handled in ~0.3s on my machine. Alas, handling merge commits is non-trivial and quite expensive as the algorithm used seems to be quadratic, causing the long runtime shown above. Interestingly, look at what a big difference one additional commit can make: $ git rev-list --count v1.6.0^..v2.28.0 44285 $ time git bisect start v2.28.0 v1.6.0^ Bisecting: 22142 revisions left to test after this (roughly 15 steps) [565301e41670825ceedf75220f2918ae76831240] Sync with 2.1.2 real 0m5.848s user 0m5.600s sys 0m0.252s The difference is caused by one of the optimizations attempting to cut down the runtime added in 1c4fea3a40 (git-rev-list --bisect: optimization, 2007-03-21): Another small optimization is whenever we find a half-way commit (that is, a commit that can reach exactly half of the commits), we stop giving counts to remaining commits, as we will not find any better commit than we just found. In this second 'git bisect start' command we happen to find a commit exactly at the halfway point and can return early, but in the first case there is no such commit, so we can't return early and end up counting the number of reachable commits from all commits in the good-bad range. However, when we have thousands of commits it's not all that important to find the _exact_ halfway point, a few commits more or less doesn't make any real difference for the bisection. So let's loosen the check in the halfway() helper to consider commits within about 0.1% of the exact halfway point as halfway as well, and rename the function to approx_halfway() accordingly. This will allow us to return early on a bigger good-bad range, even when there is no commit exactly at the halfway point, thereby reducing the runtime of the first command above considerably, from ~15s to 4.901s. Furthermore, even if there is a commit exactly at the halfway point, we might still stumble upon a commit within that 0.1% range before finding the exact halfway point, allowing us to return a bit earlier, slightly reducing the runtime of the second command from 5.848s to 5.058s. Note that this change doesn't affect good-bad ranges containing ~2000 commits or less, because that 0.1% tolerance becomes zero due to integer arithmetic; however, if the range is that small then counting the reachable commits for all commits is already fast enough anyway. Naturally, this will likely change which commits get picked at each bisection step, and, in turn, might change how many bisection steps are necessary to find the first bad commit. If the number of necessary bisection steps were to increase often, then this change could backfire, because building and testing at each step might take much longer than the time spared. OTOH, if the number of steps were to decrease, then it would be a double win. So I ran some tests to see how often that happens: picked random good and bad starting revisions at least 50k commits apart and a random first bad commit in between in git.git, and used 'git bisect run git merge-base --is-ancestor HEAD $first_bad_commit' to check the number of necessary bisection steps. After repeating all this 1000 times both with and without this patch I found that: - 146 cases needed one more bisection step than before, 149 cases needed one less step, while in the remaining 705 cases the number of steps didn't change. So the number of bisection steps does indeed change in a non-negligible number of cases, but it seems that the average number of steps doesn't change in the long run. - The first 'git bisect start' command got over 3x faster in 456 cases, so this "no commit at the exact halfway point" case seems to be common enough to care about. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-12 17:19:38 +01:00
diff = 2 * weight(p) - nr;
switch (diff) {
case -1: case 0: case 1:
return 1;
default:
bisect: loosen halfway() check for a large number of commits 'git bisect start ...' and subsequent 'git bisect (good|bad)' commands can take quite a while when the given/remaining revision range between good and bad commits is big and contains a lot of merge commits, e.g. in git.git: $ git rev-list --count v1.6.0..v2.28.0 44284 $ time git bisect start v2.28.0 v1.6.0 Bisecting: 22141 revisions left to test after this (roughly 15 steps) [e197c21807dacadc8305250baa0b9228819189d4] unable_to_lock_die(): rename function from unable_to_lock_index_die() real 0m15.472s user 0m15.220s sys 0m0.255s The majority of the runtime is spent in do_find_bisection(), where we try to find a commit as close as possible to the halfway point between the bad and good revisions, i.e. a commit from which the number of reachable commits that are in the good-bad range is half the total number of commits in that range. So we count how many commits are reachable in the good-bad range for each commit in that range, which is quick and easy for a linear history, even over 300k commits in a linear range are handled in ~0.3s on my machine. Alas, handling merge commits is non-trivial and quite expensive as the algorithm used seems to be quadratic, causing the long runtime shown above. Interestingly, look at what a big difference one additional commit can make: $ git rev-list --count v1.6.0^..v2.28.0 44285 $ time git bisect start v2.28.0 v1.6.0^ Bisecting: 22142 revisions left to test after this (roughly 15 steps) [565301e41670825ceedf75220f2918ae76831240] Sync with 2.1.2 real 0m5.848s user 0m5.600s sys 0m0.252s The difference is caused by one of the optimizations attempting to cut down the runtime added in 1c4fea3a40 (git-rev-list --bisect: optimization, 2007-03-21): Another small optimization is whenever we find a half-way commit (that is, a commit that can reach exactly half of the commits), we stop giving counts to remaining commits, as we will not find any better commit than we just found. In this second 'git bisect start' command we happen to find a commit exactly at the halfway point and can return early, but in the first case there is no such commit, so we can't return early and end up counting the number of reachable commits from all commits in the good-bad range. However, when we have thousands of commits it's not all that important to find the _exact_ halfway point, a few commits more or less doesn't make any real difference for the bisection. So let's loosen the check in the halfway() helper to consider commits within about 0.1% of the exact halfway point as halfway as well, and rename the function to approx_halfway() accordingly. This will allow us to return early on a bigger good-bad range, even when there is no commit exactly at the halfway point, thereby reducing the runtime of the first command above considerably, from ~15s to 4.901s. Furthermore, even if there is a commit exactly at the halfway point, we might still stumble upon a commit within that 0.1% range before finding the exact halfway point, allowing us to return a bit earlier, slightly reducing the runtime of the second command from 5.848s to 5.058s. Note that this change doesn't affect good-bad ranges containing ~2000 commits or less, because that 0.1% tolerance becomes zero due to integer arithmetic; however, if the range is that small then counting the reachable commits for all commits is already fast enough anyway. Naturally, this will likely change which commits get picked at each bisection step, and, in turn, might change how many bisection steps are necessary to find the first bad commit. If the number of necessary bisection steps were to increase often, then this change could backfire, because building and testing at each step might take much longer than the time spared. OTOH, if the number of steps were to decrease, then it would be a double win. So I ran some tests to see how often that happens: picked random good and bad starting revisions at least 50k commits apart and a random first bad commit in between in git.git, and used 'git bisect run git merge-base --is-ancestor HEAD $first_bad_commit' to check the number of necessary bisection steps. After repeating all this 1000 times both with and without this patch I found that: - 146 cases needed one more bisection step than before, 149 cases needed one less step, while in the remaining 705 cases the number of steps didn't change. So the number of bisection steps does indeed change in a non-negligible number of cases, but it seems that the average number of steps doesn't change in the long run. - The first 'git bisect start' command got over 3x faster in 456 cases, so this "no commit at the exact halfway point" case seems to be common enough to care about. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-12 17:19:38 +01:00
/*
* For large number of commits we are not so strict, it's
* good enough if it's within ~0.1% of the halfway point,
* e.g. 5000 is exactly halfway of 10000, but we consider
* the values [4996, 5004] as halfway as well.
*/
if (abs(diff) < nr / 1024)
return 1;
return 0;
}
}
static void show_list(const char *debug, int counted, int nr,
struct commit_list *list)
{
struct commit_list *p;
if (!DEBUG_BISECT)
return;
fprintf(stderr, "%s (%d/%d)\n", debug, counted, nr);
for (p = list; p; p = p->next) {
struct commit_list *pp;
struct commit *commit = p->item;
unsigned commit_flags = commit->object.flags;
enum object_type type;
unsigned long size;
char *buf = read_object_file(&commit->object.oid, &type,
&size);
const char *subject_start;
int subject_len;
fprintf(stderr, "%c%c%c ",
(commit_flags & TREESAME) ? ' ' : 'T',
(commit_flags & UNINTERESTING) ? 'U' : ' ',
(commit_flags & COUNTED) ? 'C' : ' ');
if (*commit_weight_at(&commit_weight, p->item))
fprintf(stderr, "%3d", weight(p));
else
fprintf(stderr, "---");
fprintf(stderr, " %.*s", 8, oid_to_hex(&commit->object.oid));
for (pp = commit->parents; pp; pp = pp->next)
fprintf(stderr, " %.*s", 8,
oid_to_hex(&pp->item->object.oid));
subject_len = find_commit_subject(buf, &subject_start);
if (subject_len)
fprintf(stderr, " %.*s", subject_len, subject_start);
fprintf(stderr, "\n");
}
}
static struct commit_list *best_bisection(struct commit_list *list, int nr)
{
struct commit_list *p, *best;
int best_distance = -1;
best = list;
for (p = list; p; p = p->next) {
int distance;
unsigned commit_flags = p->item->object.flags;
if (commit_flags & TREESAME)
continue;
distance = weight(p);
if (nr - distance < distance)
distance = nr - distance;
if (distance > best_distance) {
best = p;
best_distance = distance;
}
}
return best;
}
struct commit_dist {
struct commit *commit;
int distance;
};
static int compare_commit_dist(const void *a_, const void *b_)
{
struct commit_dist *a, *b;
a = (struct commit_dist *)a_;
b = (struct commit_dist *)b_;
if (a->distance != b->distance)
return b->distance - a->distance; /* desc sort */
return oidcmp(&a->commit->object.oid, &b->commit->object.oid);
}
static struct commit_list *best_bisection_sorted(struct commit_list *list, int nr)
{
struct commit_list *p;
struct commit_dist *array = xcalloc(nr, sizeof(*array));
struct strbuf buf = STRBUF_INIT;
int cnt, i;
for (p = list, cnt = 0; p; p = p->next) {
int distance;
unsigned commit_flags = p->item->object.flags;
if (commit_flags & TREESAME)
continue;
distance = weight(p);
if (nr - distance < distance)
distance = nr - distance;
array[cnt].commit = p->item;
array[cnt].distance = distance;
cnt++;
}
QSORT(array, cnt, compare_commit_dist);
for (p = list, i = 0; i < cnt; i++) {
struct object *obj = &(array[i].commit->object);
strbuf_reset(&buf);
strbuf_addf(&buf, "dist=%d", array[i].distance);
add_name_decoration(DECORATION_NONE, buf.buf, obj);
p->item = array[i].commit;
if (i < cnt - 1)
p = p->next;
}
if (p) {
free_commit_list(p->next);
p->next = NULL;
}
strbuf_release(&buf);
free(array);
return list;
}
/*
* zero or positive weight is the number of interesting commits it can
* reach, including itself. Especially, weight = 0 means it does not
* reach any tree-changing commits (e.g. just above uninteresting one
* but traversal is with pathspec).
*
* weight = -1 means it has one parent and its distance is yet to
* be computed.
*
* weight = -2 means it has more than one parent and its distance is
* unknown. After running count_distance() first, they will get zero
* or positive distance.
*/
static struct commit_list *do_find_bisection(struct commit_list *list,
int nr, int *weights,
unsigned bisect_flags)
{
int n, counted;
struct commit_list *p;
counted = 0;
for (n = 0, p = list; p; p = p->next) {
struct commit *commit = p->item;
unsigned commit_flags = commit->object.flags;
*commit_weight_at(&commit_weight, p->item) = &weights[n++];
switch (count_interesting_parents(commit, bisect_flags)) {
case 0:
if (!(commit_flags & TREESAME)) {
weight_set(p, 1);
counted++;
show_list("bisection 2 count one",
counted, nr, list);
}
/*
* otherwise, it is known not to reach any
* tree-changing commit and gets weight 0.
*/
break;
case 1:
weight_set(p, -1);
break;
default:
weight_set(p, -2);
break;
}
}
show_list("bisection 2 initialize", counted, nr, list);
/*
* If you have only one parent in the resulting set
* then you can reach one commit more than that parent
* can reach. So we do not have to run the expensive
* count_distance() for single strand of pearls.
*
* However, if you have more than one parents, you cannot
* just add their distance and one for yourself, since
* they usually reach the same ancestor and you would
* end up counting them twice that way.
*
* So we will first count distance of merges the usual
* way, and then fill the blanks using cheaper algorithm.
*/
for (p = list; p; p = p->next) {
if (p->item->object.flags & UNINTERESTING)
continue;
if (weight(p) != -2)
continue;
if (bisect_flags & FIND_BISECTION_FIRST_PARENT_ONLY)
BUG("shouldn't be calling count-distance in fp mode");
weight_set(p, count_distance(p));
clear_distance(list);
bisect: loosen halfway() check for a large number of commits 'git bisect start ...' and subsequent 'git bisect (good|bad)' commands can take quite a while when the given/remaining revision range between good and bad commits is big and contains a lot of merge commits, e.g. in git.git: $ git rev-list --count v1.6.0..v2.28.0 44284 $ time git bisect start v2.28.0 v1.6.0 Bisecting: 22141 revisions left to test after this (roughly 15 steps) [e197c21807dacadc8305250baa0b9228819189d4] unable_to_lock_die(): rename function from unable_to_lock_index_die() real 0m15.472s user 0m15.220s sys 0m0.255s The majority of the runtime is spent in do_find_bisection(), where we try to find a commit as close as possible to the halfway point between the bad and good revisions, i.e. a commit from which the number of reachable commits that are in the good-bad range is half the total number of commits in that range. So we count how many commits are reachable in the good-bad range for each commit in that range, which is quick and easy for a linear history, even over 300k commits in a linear range are handled in ~0.3s on my machine. Alas, handling merge commits is non-trivial and quite expensive as the algorithm used seems to be quadratic, causing the long runtime shown above. Interestingly, look at what a big difference one additional commit can make: $ git rev-list --count v1.6.0^..v2.28.0 44285 $ time git bisect start v2.28.0 v1.6.0^ Bisecting: 22142 revisions left to test after this (roughly 15 steps) [565301e41670825ceedf75220f2918ae76831240] Sync with 2.1.2 real 0m5.848s user 0m5.600s sys 0m0.252s The difference is caused by one of the optimizations attempting to cut down the runtime added in 1c4fea3a40 (git-rev-list --bisect: optimization, 2007-03-21): Another small optimization is whenever we find a half-way commit (that is, a commit that can reach exactly half of the commits), we stop giving counts to remaining commits, as we will not find any better commit than we just found. In this second 'git bisect start' command we happen to find a commit exactly at the halfway point and can return early, but in the first case there is no such commit, so we can't return early and end up counting the number of reachable commits from all commits in the good-bad range. However, when we have thousands of commits it's not all that important to find the _exact_ halfway point, a few commits more or less doesn't make any real difference for the bisection. So let's loosen the check in the halfway() helper to consider commits within about 0.1% of the exact halfway point as halfway as well, and rename the function to approx_halfway() accordingly. This will allow us to return early on a bigger good-bad range, even when there is no commit exactly at the halfway point, thereby reducing the runtime of the first command above considerably, from ~15s to 4.901s. Furthermore, even if there is a commit exactly at the halfway point, we might still stumble upon a commit within that 0.1% range before finding the exact halfway point, allowing us to return a bit earlier, slightly reducing the runtime of the second command from 5.848s to 5.058s. Note that this change doesn't affect good-bad ranges containing ~2000 commits or less, because that 0.1% tolerance becomes zero due to integer arithmetic; however, if the range is that small then counting the reachable commits for all commits is already fast enough anyway. Naturally, this will likely change which commits get picked at each bisection step, and, in turn, might change how many bisection steps are necessary to find the first bad commit. If the number of necessary bisection steps were to increase often, then this change could backfire, because building and testing at each step might take much longer than the time spared. OTOH, if the number of steps were to decrease, then it would be a double win. So I ran some tests to see how often that happens: picked random good and bad starting revisions at least 50k commits apart and a random first bad commit in between in git.git, and used 'git bisect run git merge-base --is-ancestor HEAD $first_bad_commit' to check the number of necessary bisection steps. After repeating all this 1000 times both with and without this patch I found that: - 146 cases needed one more bisection step than before, 149 cases needed one less step, while in the remaining 705 cases the number of steps didn't change. So the number of bisection steps does indeed change in a non-negligible number of cases, but it seems that the average number of steps doesn't change in the long run. - The first 'git bisect start' command got over 3x faster in 456 cases, so this "no commit at the exact halfway point" case seems to be common enough to care about. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-12 17:19:38 +01:00
/* Does it happen to be at half-way? */
if (!(bisect_flags & FIND_BISECTION_ALL) &&
approx_halfway(p, nr))
return p;
counted++;
}
show_list("bisection 2 count_distance", counted, nr, list);
while (counted < nr) {
for (p = list; p; p = p->next) {
struct commit_list *q;
unsigned commit_flags = p->item->object.flags;
if (0 <= weight(p))
continue;
for (q = p->item->parents;
q;
q = bisect_flags & FIND_BISECTION_FIRST_PARENT_ONLY ? NULL : q->next) {
if (q->item->object.flags & UNINTERESTING)
continue;
if (0 <= weight(q))
break;
}
if (!q)
continue;
/*
* weight for p is unknown but q is known.
* add one for p itself if p is to be counted,
* otherwise inherit it from q directly.
*/
if (!(commit_flags & TREESAME)) {
weight_set(p, weight(q)+1);
counted++;
show_list("bisection 2 count one",
counted, nr, list);
}
else
weight_set(p, weight(q));
bisect: loosen halfway() check for a large number of commits 'git bisect start ...' and subsequent 'git bisect (good|bad)' commands can take quite a while when the given/remaining revision range between good and bad commits is big and contains a lot of merge commits, e.g. in git.git: $ git rev-list --count v1.6.0..v2.28.0 44284 $ time git bisect start v2.28.0 v1.6.0 Bisecting: 22141 revisions left to test after this (roughly 15 steps) [e197c21807dacadc8305250baa0b9228819189d4] unable_to_lock_die(): rename function from unable_to_lock_index_die() real 0m15.472s user 0m15.220s sys 0m0.255s The majority of the runtime is spent in do_find_bisection(), where we try to find a commit as close as possible to the halfway point between the bad and good revisions, i.e. a commit from which the number of reachable commits that are in the good-bad range is half the total number of commits in that range. So we count how many commits are reachable in the good-bad range for each commit in that range, which is quick and easy for a linear history, even over 300k commits in a linear range are handled in ~0.3s on my machine. Alas, handling merge commits is non-trivial and quite expensive as the algorithm used seems to be quadratic, causing the long runtime shown above. Interestingly, look at what a big difference one additional commit can make: $ git rev-list --count v1.6.0^..v2.28.0 44285 $ time git bisect start v2.28.0 v1.6.0^ Bisecting: 22142 revisions left to test after this (roughly 15 steps) [565301e41670825ceedf75220f2918ae76831240] Sync with 2.1.2 real 0m5.848s user 0m5.600s sys 0m0.252s The difference is caused by one of the optimizations attempting to cut down the runtime added in 1c4fea3a40 (git-rev-list --bisect: optimization, 2007-03-21): Another small optimization is whenever we find a half-way commit (that is, a commit that can reach exactly half of the commits), we stop giving counts to remaining commits, as we will not find any better commit than we just found. In this second 'git bisect start' command we happen to find a commit exactly at the halfway point and can return early, but in the first case there is no such commit, so we can't return early and end up counting the number of reachable commits from all commits in the good-bad range. However, when we have thousands of commits it's not all that important to find the _exact_ halfway point, a few commits more or less doesn't make any real difference for the bisection. So let's loosen the check in the halfway() helper to consider commits within about 0.1% of the exact halfway point as halfway as well, and rename the function to approx_halfway() accordingly. This will allow us to return early on a bigger good-bad range, even when there is no commit exactly at the halfway point, thereby reducing the runtime of the first command above considerably, from ~15s to 4.901s. Furthermore, even if there is a commit exactly at the halfway point, we might still stumble upon a commit within that 0.1% range before finding the exact halfway point, allowing us to return a bit earlier, slightly reducing the runtime of the second command from 5.848s to 5.058s. Note that this change doesn't affect good-bad ranges containing ~2000 commits or less, because that 0.1% tolerance becomes zero due to integer arithmetic; however, if the range is that small then counting the reachable commits for all commits is already fast enough anyway. Naturally, this will likely change which commits get picked at each bisection step, and, in turn, might change how many bisection steps are necessary to find the first bad commit. If the number of necessary bisection steps were to increase often, then this change could backfire, because building and testing at each step might take much longer than the time spared. OTOH, if the number of steps were to decrease, then it would be a double win. So I ran some tests to see how often that happens: picked random good and bad starting revisions at least 50k commits apart and a random first bad commit in between in git.git, and used 'git bisect run git merge-base --is-ancestor HEAD $first_bad_commit' to check the number of necessary bisection steps. After repeating all this 1000 times both with and without this patch I found that: - 146 cases needed one more bisection step than before, 149 cases needed one less step, while in the remaining 705 cases the number of steps didn't change. So the number of bisection steps does indeed change in a non-negligible number of cases, but it seems that the average number of steps doesn't change in the long run. - The first 'git bisect start' command got over 3x faster in 456 cases, so this "no commit at the exact halfway point" case seems to be common enough to care about. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-12 17:19:38 +01:00
/* Does it happen to be at half-way? */
if (!(bisect_flags & FIND_BISECTION_ALL) &&
approx_halfway(p, nr))
return p;
}
}
show_list("bisection 2 counted all", counted, nr, list);
if (!(bisect_flags & FIND_BISECTION_ALL))
return best_bisection(list, nr);
else
return best_bisection_sorted(list, nr);
}
void find_bisection(struct commit_list **commit_list, int *reaches,
int *all, unsigned bisect_flags)
{
int nr, on_list;
struct commit_list *list, *p, *best, *next, *last;
int *weights;
show_list("bisection 2 entry", 0, 0, *commit_list);
init_commit_weight(&commit_weight);
/*
* Count the number of total and tree-changing items on the
* list, while reversing the list.
*/
for (nr = on_list = 0, last = NULL, p = *commit_list;
p;
p = next) {
unsigned commit_flags = p->item->object.flags;
next = p->next;
if (commit_flags & UNINTERESTING) {
free(p);
continue;
}
p->next = last;
last = p;
if (!(commit_flags & TREESAME))
nr++;
on_list++;
}
list = last;
show_list("bisection 2 sorted", 0, nr, list);
*all = nr;
CALLOC_ARRAY(weights, on_list);
/* Do the real work of finding bisection commit. */
best = do_find_bisection(list, nr, weights, bisect_flags);
if (best) {
if (!(bisect_flags & FIND_BISECTION_ALL)) {
list->item = best->item;
free_commit_list(list->next);
best = list;
best->next = NULL;
}
*reaches = weight(best);
}
free(weights);
*commit_list = best;
clear_commit_weight(&commit_weight);
}
static int register_ref(const char *refname, const struct object_id *oid,
int flags, void *cb_data)
{
struct strbuf good_prefix = STRBUF_INIT;
strbuf_addstr(&good_prefix, term_good);
strbuf_addstr(&good_prefix, "-");
if (!strcmp(refname, term_bad)) {
current_bad_oid = xmalloc(sizeof(*current_bad_oid));
oidcpy(current_bad_oid, oid);
} else if (starts_with(refname, good_prefix.buf)) {
oid_array_append(&good_revs, oid);
} else if (starts_with(refname, "skip-")) {
oid_array_append(&skipped_revs, oid);
}
strbuf_release(&good_prefix);
return 0;
}
static int read_bisect_refs(void)
{
return for_each_ref_in("refs/bisect/", register_ref, NULL);
}
memoize common git-path "constant" files One of the most common uses of git_path() is to pass a constant, like git_path("MERGE_MSG"). This has two drawbacks: 1. The return value is a static buffer, and the lifetime is dependent on other calls to git_path, etc. 2. There's no compile-time checking of the pathname. This is OK for a one-off (after all, we have to spell it correctly at least once), but many of these constant strings appear throughout the code. This patch introduces a series of functions to "memoize" these strings, which are essentially globals for the lifetime of the program. We compute the value once, take ownership of the buffer, and return the cached value for subsequent calls. cache.h provides a helper macro for defining these functions as one-liners, and defines a few common ones for global use. Using a macro is a little bit gross, but it does nicely document the purpose of the functions. If we need to touch them all later (e.g., because we learned how to change the git_dir variable at runtime, and need to invalidate all of the stored values), it will be much easier to have the complete list. Note that the shared-global functions have separate, manual declarations. We could do something clever with the macros (e.g., expand it to a declaration in some places, and a declaration _and_ a definition in path.c). But there aren't that many, and it's probably better to stay away from too-magical macros. Likewise, if we abandon the C preprocessor in favor of generating these with a script, we could get much fancier. E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz". But the small amount of saved typing is probably not worth the resulting confusion to readers who want to grep for the function's definition. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10 11:38:57 +02:00
static GIT_PATH_FUNC(git_path_bisect_names, "BISECT_NAMES")
static GIT_PATH_FUNC(git_path_bisect_expected_rev, "BISECT_EXPECTED_REV")
static GIT_PATH_FUNC(git_path_bisect_ancestors_ok, "BISECT_ANCESTORS_OK")
static GIT_PATH_FUNC(git_path_bisect_run, "BISECT_RUN")
static GIT_PATH_FUNC(git_path_bisect_start, "BISECT_START")
static GIT_PATH_FUNC(git_path_bisect_log, "BISECT_LOG")
static GIT_PATH_FUNC(git_path_bisect_terms, "BISECT_TERMS")
static GIT_PATH_FUNC(git_path_bisect_first_parent, "BISECT_FIRST_PARENT")
static GIT_PATH_FUNC(git_path_head_name, "head-name")
memoize common git-path "constant" files One of the most common uses of git_path() is to pass a constant, like git_path("MERGE_MSG"). This has two drawbacks: 1. The return value is a static buffer, and the lifetime is dependent on other calls to git_path, etc. 2. There's no compile-time checking of the pathname. This is OK for a one-off (after all, we have to spell it correctly at least once), but many of these constant strings appear throughout the code. This patch introduces a series of functions to "memoize" these strings, which are essentially globals for the lifetime of the program. We compute the value once, take ownership of the buffer, and return the cached value for subsequent calls. cache.h provides a helper macro for defining these functions as one-liners, and defines a few common ones for global use. Using a macro is a little bit gross, but it does nicely document the purpose of the functions. If we need to touch them all later (e.g., because we learned how to change the git_dir variable at runtime, and need to invalidate all of the stored values), it will be much easier to have the complete list. Note that the shared-global functions have separate, manual declarations. We could do something clever with the macros (e.g., expand it to a declaration in some places, and a declaration _and_ a definition in path.c). But there aren't that many, and it's probably better to stay away from too-magical macros. Likewise, if we abandon the C preprocessor in favor of generating these with a script, we could get much fancier. E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz". But the small amount of saved typing is probably not worth the resulting confusion to readers who want to grep for the function's definition. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10 11:38:57 +02:00
static void read_bisect_paths(struct strvec *array)
{
struct strbuf str = STRBUF_INIT;
memoize common git-path "constant" files One of the most common uses of git_path() is to pass a constant, like git_path("MERGE_MSG"). This has two drawbacks: 1. The return value is a static buffer, and the lifetime is dependent on other calls to git_path, etc. 2. There's no compile-time checking of the pathname. This is OK for a one-off (after all, we have to spell it correctly at least once), but many of these constant strings appear throughout the code. This patch introduces a series of functions to "memoize" these strings, which are essentially globals for the lifetime of the program. We compute the value once, take ownership of the buffer, and return the cached value for subsequent calls. cache.h provides a helper macro for defining these functions as one-liners, and defines a few common ones for global use. Using a macro is a little bit gross, but it does nicely document the purpose of the functions. If we need to touch them all later (e.g., because we learned how to change the git_dir variable at runtime, and need to invalidate all of the stored values), it will be much easier to have the complete list. Note that the shared-global functions have separate, manual declarations. We could do something clever with the macros (e.g., expand it to a declaration in some places, and a declaration _and_ a definition in path.c). But there aren't that many, and it's probably better to stay away from too-magical macros. Likewise, if we abandon the C preprocessor in favor of generating these with a script, we could get much fancier. E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz". But the small amount of saved typing is probably not worth the resulting confusion to readers who want to grep for the function's definition. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10 11:38:57 +02:00
const char *filename = git_path_bisect_names();
FILE *fp = xfopen(filename, "r");
while (strbuf_getline_lf(&str, fp) != EOF) {
strbuf_trim(&str);
if (sq_dequote_to_strvec(str.buf, array))
die(_("Badly quoted content in file '%s': %s"),
filename, str.buf);
}
strbuf_release(&str);
fclose(fp);
}
static char *join_oid_array_hex(struct oid_array *array, char delim)
{
struct strbuf joined_hexs = STRBUF_INIT;
int i;
for (i = 0; i < array->nr; i++) {
strbuf_addstr(&joined_hexs, oid_to_hex(array->oid + i));
if (i + 1 < array->nr)
strbuf_addch(&joined_hexs, delim);
}
return strbuf_detach(&joined_hexs, NULL);
}
/*
* In this function, passing a not NULL skipped_first is very special.
* It means that we want to know if the first commit in the list is
* skipped because we will want to test a commit away from it if it is
* indeed skipped.
* So if the first commit is skipped, we cannot take the shortcut to
* just "return list" when we find the first non skipped commit, we
* have to return a fully filtered list.
*
* We use (*skipped_first == -1) to mean "it has been found that the
* first commit is not skipped". In this case *skipped_first is set back
* to 0 just before the function returns.
*/
struct commit_list *filter_skipped(struct commit_list *list,
struct commit_list **tried,
int show_all,
int *count,
int *skipped_first)
{
struct commit_list *filtered = NULL, **f = &filtered;
*tried = NULL;
if (skipped_first)
*skipped_first = 0;
if (count)
*count = 0;
if (!skipped_revs.nr)
return list;
while (list) {
struct commit_list *next = list->next;
list->next = NULL;
if (0 <= oid_array_lookup(&skipped_revs, &list->item->object.oid)) {
if (skipped_first && !*skipped_first)
*skipped_first = 1;
/* Move current to tried list */
*tried = list;
tried = &list->next;
} else {
if (!show_all) {
if (!skipped_first || !*skipped_first)
return list;
} else if (skipped_first && !*skipped_first) {
/* This means we know it's not skipped */
*skipped_first = -1;
}
/* Move current to filtered list */
*f = list;
f = &list->next;
if (count)
(*count)++;
}
list = next;
}
if (skipped_first && *skipped_first == -1)
*skipped_first = 0;
return filtered;
}
#define PRN_MODULO 32768
/*
* This is a pseudo random number generator based on "man 3 rand".
* It is not used properly because the seed is the argument and it
* is increased by one between each call, but that should not matter
* for this application.
*/
static unsigned get_prn(unsigned count)
{
count = count * 1103515245 + 12345;
return (count/65536) % PRN_MODULO;
}
/*
* Custom integer square root from
* https://en.wikipedia.org/wiki/Integer_square_root
*/
static int sqrti(int val)
{
float d, x = val;
if (!val)
return 0;
do {
float y = (x + (float)val / x) / 2;
d = (y > x) ? y - x : x - y;
x = y;
} while (d >= 0.5);
return (int)x;
}
static struct commit_list *skip_away(struct commit_list *list, int count)
{
struct commit_list *cur, *previous;