2023-02-24 01:09:24 +01:00
|
|
|
#include "git-compat-util.h"
|
|
|
|
#include "alloc.h"
|
2018-07-20 18:33:02 +02:00
|
|
|
#include "commit.h"
|
2018-07-20 18:33:08 +02:00
|
|
|
#include "commit-graph.h"
|
2018-07-20 18:33:06 +02:00
|
|
|
#include "decorate.h"
|
2023-02-24 01:09:27 +01:00
|
|
|
#include "hex.h"
|
2018-07-20 18:33:06 +02:00
|
|
|
#include "prio-queue.h"
|
|
|
|
#include "tree.h"
|
2018-08-28 23:36:57 +02:00
|
|
|
#include "ref-filter.h"
|
2018-07-20 18:33:06 +02:00
|
|
|
#include "revision.h"
|
|
|
|
#include "tag.h"
|
2018-07-20 18:33:02 +02:00
|
|
|
#include "commit-reach.h"
|
|
|
|
|
|
|
|
/* Remember to update object flag allocation in object.h */
|
|
|
|
#define PARENT1 (1u<<16)
|
|
|
|
#define PARENT2 (1u<<17)
|
|
|
|
#define STALE (1u<<18)
|
|
|
|
#define RESULT (1u<<19)
|
|
|
|
|
|
|
|
static const unsigned all_flags = (PARENT1 | PARENT2 | STALE | RESULT);
|
|
|
|
|
2021-02-19 13:34:08 +01:00
|
|
|
static int compare_commits_by_gen(const void *_a, const void *_b)
|
|
|
|
{
|
|
|
|
const struct commit *a = *(const struct commit * const *)_a;
|
|
|
|
const struct commit *b = *(const struct commit * const *)_b;
|
|
|
|
|
|
|
|
timestamp_t generation_a = commit_graph_generation(a);
|
|
|
|
timestamp_t generation_b = commit_graph_generation(b);
|
|
|
|
|
|
|
|
if (generation_a < generation_b)
|
|
|
|
return -1;
|
|
|
|
if (generation_a > generation_b)
|
|
|
|
return 1;
|
2021-02-19 13:34:09 +01:00
|
|
|
if (a->date < b->date)
|
|
|
|
return -1;
|
|
|
|
if (a->date > b->date)
|
|
|
|
return 1;
|
2021-02-19 13:34:08 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-07-20 18:33:02 +02:00
|
|
|
static int queue_has_nonstale(struct prio_queue *queue)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < queue->nr; i++) {
|
|
|
|
struct commit *commit = queue->array[i].data;
|
|
|
|
if (!(commit->object.flags & STALE))
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* all input commits in one and twos[] must have been parsed! */
|
2018-11-14 01:12:51 +01:00
|
|
|
static struct commit_list *paint_down_to_common(struct repository *r,
|
|
|
|
struct commit *one, int n,
|
2018-07-20 18:33:02 +02:00
|
|
|
struct commit **twos,
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t min_generation)
|
2018-07-20 18:33:02 +02:00
|
|
|
{
|
|
|
|
struct prio_queue queue = { compare_commits_by_gen_then_commit_date };
|
|
|
|
struct commit_list *result = NULL;
|
|
|
|
int i;
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t last_gen = GENERATION_NUMBER_INFINITY;
|
2018-07-20 18:33:02 +02:00
|
|
|
|
commit-reach: use corrected commit dates in paint_down_to_common()
091f4cf (commit: don't use generation numbers if not needed,
2018-08-30) changed paint_down_to_common() to use commit dates instead
of generation numbers v1 (topological levels) as the performance
regressed on certain topologies. With generation number v2 (corrected
commit dates) implemented, we no longer have to rely on commit dates and
can use generation numbers.
For example, the command `git merge-base v4.8 v4.9` on the Linux
repository walks 167468 commits, taking 0.135s for committer date and
167496 commits, taking 0.157s for corrected committer date respectively.
While using corrected commit dates, Git walks nearly the same number of
commits as commit date, the process is slower as for each comparision we
have to access a commit-slab (for corrected committer date) instead of
accessing struct member (for committer date).
This change incidentally broke the fragile t6404-recursive-merge test.
t6404-recursive-merge sets up a unique repository where all commits have
the same committer date without a well-defined merge-base.
While running tests with GIT_TEST_COMMIT_GRAPH unset, we use committer
date as a heuristic in paint_down_to_common(). 6404.1 'combined merge
conflicts' merges commits in the order:
- Merge C with B to form an intermediate commit.
- Merge the intermediate commit with A.
With GIT_TEST_COMMIT_GRAPH=1, we write a commit-graph and subsequently
use the corrected committer date, which changes the order in which
commits are merged:
- Merge A with B to form an intermediate commit.
- Merge the intermediate commit with C.
While resulting repositories are equivalent, 6404.4 'virtual trees were
processed' fails with GIT_TEST_COMMIT_GRAPH=1 as we are selecting
different merge-bases and thus have different object ids for the
intermediate commits.
As this has already causes problems (as noted in 859fdc0 (commit-graph:
define GIT_TEST_COMMIT_GRAPH, 2018-08-29)), we disable commit graph
within t6404-recursive-merge.
Signed-off-by: Abhishek Kumar <abhishekkumar8222@gmail.com>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-16 19:11:17 +01:00
|
|
|
if (!min_generation && !corrected_commit_dates_enabled(r))
|
2018-09-17 22:53:52 +02:00
|
|
|
queue.compare = compare_commits_by_commit_date;
|
|
|
|
|
2018-07-20 18:33:02 +02:00
|
|
|
one->object.flags |= PARENT1;
|
|
|
|
if (!n) {
|
|
|
|
commit_list_append(one, &result);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
prio_queue_put(&queue, one);
|
|
|
|
|
|
|
|
for (i = 0; i < n; i++) {
|
|
|
|
twos[i]->object.flags |= PARENT2;
|
|
|
|
prio_queue_put(&queue, twos[i]);
|
|
|
|
}
|
|
|
|
|
|
|
|
while (queue_has_nonstale(&queue)) {
|
|
|
|
struct commit *commit = prio_queue_get(&queue);
|
|
|
|
struct commit_list *parents;
|
|
|
|
int flags;
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t generation = commit_graph_generation(commit);
|
2018-07-20 18:33:02 +02:00
|
|
|
|
2020-06-17 11:14:11 +02:00
|
|
|
if (min_generation && generation > last_gen)
|
2021-01-16 19:11:13 +01:00
|
|
|
BUG("bad generation skip %"PRItime" > %"PRItime" at %s",
|
2020-06-17 11:14:11 +02:00
|
|
|
generation, last_gen,
|
2018-07-20 18:33:02 +02:00
|
|
|
oid_to_hex(&commit->object.oid));
|
2020-06-17 11:14:11 +02:00
|
|
|
last_gen = generation;
|
2018-07-20 18:33:02 +02:00
|
|
|
|
2020-06-17 11:14:11 +02:00
|
|
|
if (generation < min_generation)
|
2018-07-20 18:33:02 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
flags = commit->object.flags & (PARENT1 | PARENT2 | STALE);
|
|
|
|
if (flags == (PARENT1 | PARENT2)) {
|
|
|
|
if (!(commit->object.flags & RESULT)) {
|
|
|
|
commit->object.flags |= RESULT;
|
|
|
|
commit_list_insert_by_date(commit, &result);
|
|
|
|
}
|
|
|
|
/* Mark parents of a found merge stale */
|
|
|
|
flags |= STALE;
|
|
|
|
}
|
|
|
|
parents = commit->parents;
|
|
|
|
while (parents) {
|
|
|
|
struct commit *p = parents->item;
|
|
|
|
parents = parents->next;
|
|
|
|
if ((p->object.flags & flags) == flags)
|
|
|
|
continue;
|
2018-11-14 01:12:51 +01:00
|
|
|
if (repo_parse_commit(r, p))
|
2018-07-20 18:33:02 +02:00
|
|
|
return NULL;
|
|
|
|
p->object.flags |= flags;
|
|
|
|
prio_queue_put(&queue, p);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
clear_prio_queue(&queue);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2018-11-14 01:12:52 +01:00
|
|
|
static struct commit_list *merge_bases_many(struct repository *r,
|
|
|
|
struct commit *one, int n,
|
|
|
|
struct commit **twos)
|
2018-07-20 18:33:02 +02:00
|
|
|
{
|
|
|
|
struct commit_list *list = NULL;
|
|
|
|
struct commit_list *result = NULL;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < n; i++) {
|
|
|
|
if (one == twos[i])
|
|
|
|
/*
|
|
|
|
* We do not mark this even with RESULT so we do not
|
|
|
|
* have to clean it up.
|
|
|
|
*/
|
|
|
|
return commit_list_insert(one, &result);
|
|
|
|
}
|
|
|
|
|
2018-11-14 01:12:52 +01:00
|
|
|
if (repo_parse_commit(r, one))
|
2018-07-20 18:33:02 +02:00
|
|
|
return NULL;
|
|
|
|
for (i = 0; i < n; i++) {
|
2018-11-14 01:12:52 +01:00
|
|
|
if (repo_parse_commit(r, twos[i]))
|
2018-07-20 18:33:02 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2018-11-14 01:12:52 +01:00
|
|
|
list = paint_down_to_common(r, one, n, twos, 0);
|
2018-07-20 18:33:02 +02:00
|
|
|
|
|
|
|
while (list) {
|
|
|
|
struct commit *commit = pop_commit(&list);
|
|
|
|
if (!(commit->object.flags & STALE))
|
|
|
|
commit_list_insert_by_date(commit, &result);
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct commit_list *get_octopus_merge_bases(struct commit_list *in)
|
|
|
|
{
|
|
|
|
struct commit_list *i, *j, *k, *ret = NULL;
|
|
|
|
|
|
|
|
if (!in)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
commit_list_insert(in->item, &ret);
|
|
|
|
|
|
|
|
for (i = in->next; i; i = i->next) {
|
|
|
|
struct commit_list *new_commits = NULL, *end = NULL;
|
|
|
|
|
|
|
|
for (j = ret; j; j = j->next) {
|
|
|
|
struct commit_list *bases;
|
2023-03-28 15:58:47 +02:00
|
|
|
bases = repo_get_merge_bases(the_repository, i->item,
|
|
|
|
j->item);
|
2018-07-20 18:33:02 +02:00
|
|
|
if (!new_commits)
|
|
|
|
new_commits = bases;
|
|
|
|
else
|
|
|
|
end->next = bases;
|
|
|
|
for (k = bases; k; k = k->next)
|
|
|
|
end = k;
|
|
|
|
}
|
|
|
|
ret = new_commits;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
static int remove_redundant_no_gen(struct repository *r,
|
|
|
|
struct commit **array, int cnt)
|
2018-07-20 18:33:02 +02:00
|
|
|
{
|
|
|
|
struct commit **work;
|
|
|
|
unsigned char *redundant;
|
|
|
|
int *filled_index;
|
|
|
|
int i, j, filled;
|
|
|
|
|
2021-03-13 17:17:22 +01:00
|
|
|
CALLOC_ARRAY(work, cnt);
|
2018-07-20 18:33:02 +02:00
|
|
|
redundant = xcalloc(cnt, 1);
|
|
|
|
ALLOC_ARRAY(filled_index, cnt - 1);
|
|
|
|
|
|
|
|
for (i = 0; i < cnt; i++)
|
2018-11-14 01:12:53 +01:00
|
|
|
repo_parse_commit(r, array[i]);
|
2018-07-20 18:33:02 +02:00
|
|
|
for (i = 0; i < cnt; i++) {
|
|
|
|
struct commit_list *common;
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t min_generation = commit_graph_generation(array[i]);
|
2018-07-20 18:33:02 +02:00
|
|
|
|
|
|
|
if (redundant[i])
|
|
|
|
continue;
|
|
|
|
for (j = filled = 0; j < cnt; j++) {
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t curr_generation;
|
2018-07-20 18:33:02 +02:00
|
|
|
if (i == j || redundant[j])
|
|
|
|
continue;
|
|
|
|
filled_index[filled] = j;
|
|
|
|
work[filled++] = array[j];
|
|
|
|
|
2020-06-17 11:14:11 +02:00
|
|
|
curr_generation = commit_graph_generation(array[j]);
|
|
|
|
if (curr_generation < min_generation)
|
|
|
|
min_generation = curr_generation;
|
2018-07-20 18:33:02 +02:00
|
|
|
}
|
2018-11-14 01:12:53 +01:00
|
|
|
common = paint_down_to_common(r, array[i], filled,
|
2018-11-14 01:12:51 +01:00
|
|
|
work, min_generation);
|
2018-07-20 18:33:02 +02:00
|
|
|
if (array[i]->object.flags & PARENT2)
|
|
|
|
redundant[i] = 1;
|
|
|
|
for (j = 0; j < filled; j++)
|
|
|
|
if (work[j]->object.flags & PARENT1)
|
|
|
|
redundant[filled_index[j]] = 1;
|
|
|
|
clear_commit_marks(array[i], all_flags);
|
|
|
|
clear_commit_marks_many(filled, work, all_flags);
|
|
|
|
free_commit_list(common);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now collect the result */
|
|
|
|
COPY_ARRAY(work, array, cnt);
|
|
|
|
for (i = filled = 0; i < cnt; i++)
|
|
|
|
if (!redundant[i])
|
|
|
|
array[filled++] = work[i];
|
|
|
|
free(work);
|
|
|
|
free(redundant);
|
|
|
|
free(filled_index);
|
|
|
|
return filled;
|
|
|
|
}
|
|
|
|
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
static int remove_redundant_with_gen(struct repository *r,
|
|
|
|
struct commit **array, int cnt)
|
|
|
|
{
|
2021-02-19 13:34:09 +01:00
|
|
|
int i, count_non_stale = 0, count_still_independent = cnt;
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
timestamp_t min_generation = GENERATION_NUMBER_INFINITY;
|
commit-reach: stale commits may prune generation further
The remove_redundant_with_gen() algorithm performs a depth-first-search
to find commits in the 'array' list, starting at the parents of each
commit in 'array'. The result is that commits in 'array' are marked
STALE when they are reachable from another commit in 'array'.
This depth-first-search is fast when commits lie on or near the
first-parent history of the higher commits. The search terminates early
if all but one commit becomes marked STALE.
However, it is possible that there are two independent commits with high
generation number. In that case, the depth-first-search might languish
by searching in lower generations due to the fixed min_generation used
throughout the method.
With the expectation that commits with lower generation are expected to
become STALE more often, we can optimize further by increasing that
min_generation boundary upon discovery of the commit with minimum
generation.
We must first sort the commits in 'array' by generation. We cannot sort
'array' itself since it must preserve relative order among the returned
results (see revision.c:mark_redundant_parents() for an example).
This simplifies the initialization of min_generation, but it also allows
us to increase the new min_generation when we find the commit with
smallest generation remaining.
This requires more than two commits in order to test, so I used the
Linux kernel repository with a few commits that are slightly off of the
first-parent history. I timed the following command:
git merge-base --independent 2ecedd756908 d2360a398f0b \
1253935ad801 160bab43419e 0e2209629fec 1d0e16ac1a9e
The first two commits have similar generation and are near the v5.10
tag. Commit 160bab43419e is off of the first-parent history behind v5.5,
while the others are scattered somewhere reachable from v5.9. This is
designed to demonstrate the optimization, as that commit within v5.5
would normally cause a lot of extra commit walking.
Since remove_redundant_with_alg() is called only when at least one of
the input commits has a finite generation number, this algorithm is
tested with a commit-graph generated starting at a number of different
tags, the earliest being v5.5.
commit-graph at v5.5:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 864ms |
| *_with_gen() (before) | 858ms |
| *_with_gen() (after) | 810ms |
commit-graph at v5.7:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 625ms |
| *_with_gen() (before) | 572ms |
| *_with_gen() (after) | 517ms |
commit-graph at v5.9:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 268ms |
| *_with_gen() (before) | 224ms |
| *_with_gen() (after) | 202ms |
commit-graph at v5.10:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 72ms |
| *_with_gen() (before) | 37ms |
| *_with_gen() (after) | 9ms |
Note that these are only modest improvements for the case where the two
independent commits are not in the commit-graph (not until v5.10). All
algorithms get faster as more commits are indexed, which is not a
surprise. However, the cost of walking extra commits is more and more
prevalent in relative terms as more commits are indexed. Finally, the
last case allows us to jump to the minimum generation between the last
two commits (that are actually independent) so we greatly reduce the
cost in that case.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:10 +01:00
|
|
|
struct commit **walk_start, **sorted;
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
size_t walk_start_nr = 0, walk_start_alloc = cnt;
|
commit-reach: stale commits may prune generation further
The remove_redundant_with_gen() algorithm performs a depth-first-search
to find commits in the 'array' list, starting at the parents of each
commit in 'array'. The result is that commits in 'array' are marked
STALE when they are reachable from another commit in 'array'.
This depth-first-search is fast when commits lie on or near the
first-parent history of the higher commits. The search terminates early
if all but one commit becomes marked STALE.
However, it is possible that there are two independent commits with high
generation number. In that case, the depth-first-search might languish
by searching in lower generations due to the fixed min_generation used
throughout the method.
With the expectation that commits with lower generation are expected to
become STALE more often, we can optimize further by increasing that
min_generation boundary upon discovery of the commit with minimum
generation.
We must first sort the commits in 'array' by generation. We cannot sort
'array' itself since it must preserve relative order among the returned
results (see revision.c:mark_redundant_parents() for an example).
This simplifies the initialization of min_generation, but it also allows
us to increase the new min_generation when we find the commit with
smallest generation remaining.
This requires more than two commits in order to test, so I used the
Linux kernel repository with a few commits that are slightly off of the
first-parent history. I timed the following command:
git merge-base --independent 2ecedd756908 d2360a398f0b \
1253935ad801 160bab43419e 0e2209629fec 1d0e16ac1a9e
The first two commits have similar generation and are near the v5.10
tag. Commit 160bab43419e is off of the first-parent history behind v5.5,
while the others are scattered somewhere reachable from v5.9. This is
designed to demonstrate the optimization, as that commit within v5.5
would normally cause a lot of extra commit walking.
Since remove_redundant_with_alg() is called only when at least one of
the input commits has a finite generation number, this algorithm is
tested with a commit-graph generated starting at a number of different
tags, the earliest being v5.5.
commit-graph at v5.5:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 864ms |
| *_with_gen() (before) | 858ms |
| *_with_gen() (after) | 810ms |
commit-graph at v5.7:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 625ms |
| *_with_gen() (before) | 572ms |
| *_with_gen() (after) | 517ms |
commit-graph at v5.9:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 268ms |
| *_with_gen() (before) | 224ms |
| *_with_gen() (after) | 202ms |
commit-graph at v5.10:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 72ms |
| *_with_gen() (before) | 37ms |
| *_with_gen() (after) | 9ms |
Note that these are only modest improvements for the case where the two
independent commits are not in the commit-graph (not until v5.10). All
algorithms get faster as more commits are indexed, which is not a
surprise. However, the cost of walking extra commits is more and more
prevalent in relative terms as more commits are indexed. Finally, the
last case allows us to jump to the minimum generation between the last
two commits (that are actually independent) so we greatly reduce the
cost in that case.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:10 +01:00
|
|
|
int min_gen_pos = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sort the input by generation number, ascending. This allows
|
|
|
|
* us to increase the "min_generation" limit when we discover
|
|
|
|
* the commit with lowest generation is STALE. The index
|
|
|
|
* min_gen_pos points to the current position within 'array'
|
|
|
|
* that is not yet known to be STALE.
|
|
|
|
*/
|
2023-01-01 22:16:48 +01:00
|
|
|
DUP_ARRAY(sorted, array, cnt);
|
commit-reach: stale commits may prune generation further
The remove_redundant_with_gen() algorithm performs a depth-first-search
to find commits in the 'array' list, starting at the parents of each
commit in 'array'. The result is that commits in 'array' are marked
STALE when they are reachable from another commit in 'array'.
This depth-first-search is fast when commits lie on or near the
first-parent history of the higher commits. The search terminates early
if all but one commit becomes marked STALE.
However, it is possible that there are two independent commits with high
generation number. In that case, the depth-first-search might languish
by searching in lower generations due to the fixed min_generation used
throughout the method.
With the expectation that commits with lower generation are expected to
become STALE more often, we can optimize further by increasing that
min_generation boundary upon discovery of the commit with minimum
generation.
We must first sort the commits in 'array' by generation. We cannot sort
'array' itself since it must preserve relative order among the returned
results (see revision.c:mark_redundant_parents() for an example).
This simplifies the initialization of min_generation, but it also allows
us to increase the new min_generation when we find the commit with
smallest generation remaining.
This requires more than two commits in order to test, so I used the
Linux kernel repository with a few commits that are slightly off of the
first-parent history. I timed the following command:
git merge-base --independent 2ecedd756908 d2360a398f0b \
1253935ad801 160bab43419e 0e2209629fec 1d0e16ac1a9e
The first two commits have similar generation and are near the v5.10
tag. Commit 160bab43419e is off of the first-parent history behind v5.5,
while the others are scattered somewhere reachable from v5.9. This is
designed to demonstrate the optimization, as that commit within v5.5
would normally cause a lot of extra commit walking.
Since remove_redundant_with_alg() is called only when at least one of
the input commits has a finite generation number, this algorithm is
tested with a commit-graph generated starting at a number of different
tags, the earliest being v5.5.
commit-graph at v5.5:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 864ms |
| *_with_gen() (before) | 858ms |
| *_with_gen() (after) | 810ms |
commit-graph at v5.7:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 625ms |
| *_with_gen() (before) | 572ms |
| *_with_gen() (after) | 517ms |
commit-graph at v5.9:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 268ms |
| *_with_gen() (before) | 224ms |
| *_with_gen() (after) | 202ms |
commit-graph at v5.10:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 72ms |
| *_with_gen() (before) | 37ms |
| *_with_gen() (after) | 9ms |
Note that these are only modest improvements for the case where the two
independent commits are not in the commit-graph (not until v5.10). All
algorithms get faster as more commits are indexed, which is not a
surprise. However, the cost of walking extra commits is more and more
prevalent in relative terms as more commits are indexed. Finally, the
last case allows us to jump to the minimum generation between the last
two commits (that are actually independent) so we greatly reduce the
cost in that case.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:10 +01:00
|
|
|
QSORT(sorted, cnt, compare_commits_by_gen);
|
|
|
|
min_generation = commit_graph_generation(sorted[0]);
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
|
|
|
|
ALLOC_ARRAY(walk_start, walk_start_alloc);
|
|
|
|
|
|
|
|
/* Mark all parents of the input as STALE */
|
|
|
|
for (i = 0; i < cnt; i++) {
|
|
|
|
struct commit_list *parents;
|
|
|
|
|
|
|
|
repo_parse_commit(r, array[i]);
|
2021-02-19 13:34:09 +01:00
|
|
|
array[i]->object.flags |= RESULT;
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
parents = array[i]->parents;
|
|
|
|
|
|
|
|
while (parents) {
|
|
|
|
repo_parse_commit(r, parents->item);
|
|
|
|
if (!(parents->item->object.flags & STALE)) {
|
|
|
|
parents->item->object.flags |= STALE;
|
|
|
|
ALLOC_GROW(walk_start, walk_start_nr + 1, walk_start_alloc);
|
|
|
|
walk_start[walk_start_nr++] = parents->item;
|
|
|
|
}
|
|
|
|
parents = parents->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-02-19 13:34:09 +01:00
|
|
|
QSORT(walk_start, walk_start_nr, compare_commits_by_gen);
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
|
2021-02-19 13:34:09 +01:00
|
|
|
/* remove STALE bit for now to allow walking through parents */
|
|
|
|
for (i = 0; i < walk_start_nr; i++)
|
|
|
|
walk_start[i]->object.flags &= ~STALE;
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
|
2021-02-19 13:34:09 +01:00
|
|
|
/*
|
|
|
|
* Start walking from the highest generation. Hopefully, it will
|
|
|
|
* find all other items during the first-parent walk, and we can
|
|
|
|
* terminate early. Otherwise, we will do the same amount of work
|
|
|
|
* as before.
|
|
|
|
*/
|
|
|
|
for (i = walk_start_nr - 1; i >= 0 && count_still_independent > 1; i--) {
|
|
|
|
/* push the STALE bits up to min generation */
|
|
|
|
struct commit_list *stack = NULL;
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
|
2021-02-19 13:34:09 +01:00
|
|
|
commit_list_insert(walk_start[i], &stack);
|
|
|
|
walk_start[i]->object.flags |= STALE;
|
|
|
|
|
|
|
|
while (stack) {
|
|
|
|
struct commit_list *parents;
|
|
|
|
struct commit *c = stack->item;
|
|
|
|
|
|
|
|
repo_parse_commit(r, c);
|
|
|
|
|
|
|
|
if (c->object.flags & RESULT) {
|
|
|
|
c->object.flags &= ~RESULT;
|
|
|
|
if (--count_still_independent <= 1)
|
|
|
|
break;
|
commit-reach: stale commits may prune generation further
The remove_redundant_with_gen() algorithm performs a depth-first-search
to find commits in the 'array' list, starting at the parents of each
commit in 'array'. The result is that commits in 'array' are marked
STALE when they are reachable from another commit in 'array'.
This depth-first-search is fast when commits lie on or near the
first-parent history of the higher commits. The search terminates early
if all but one commit becomes marked STALE.
However, it is possible that there are two independent commits with high
generation number. In that case, the depth-first-search might languish
by searching in lower generations due to the fixed min_generation used
throughout the method.
With the expectation that commits with lower generation are expected to
become STALE more often, we can optimize further by increasing that
min_generation boundary upon discovery of the commit with minimum
generation.
We must first sort the commits in 'array' by generation. We cannot sort
'array' itself since it must preserve relative order among the returned
results (see revision.c:mark_redundant_parents() for an example).
This simplifies the initialization of min_generation, but it also allows
us to increase the new min_generation when we find the commit with
smallest generation remaining.
This requires more than two commits in order to test, so I used the
Linux kernel repository with a few commits that are slightly off of the
first-parent history. I timed the following command:
git merge-base --independent 2ecedd756908 d2360a398f0b \
1253935ad801 160bab43419e 0e2209629fec 1d0e16ac1a9e
The first two commits have similar generation and are near the v5.10
tag. Commit 160bab43419e is off of the first-parent history behind v5.5,
while the others are scattered somewhere reachable from v5.9. This is
designed to demonstrate the optimization, as that commit within v5.5
would normally cause a lot of extra commit walking.
Since remove_redundant_with_alg() is called only when at least one of
the input commits has a finite generation number, this algorithm is
tested with a commit-graph generated starting at a number of different
tags, the earliest being v5.5.
commit-graph at v5.5:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 864ms |
| *_with_gen() (before) | 858ms |
| *_with_gen() (after) | 810ms |
commit-graph at v5.7:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 625ms |
| *_with_gen() (before) | 572ms |
| *_with_gen() (after) | 517ms |
commit-graph at v5.9:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 268ms |
| *_with_gen() (before) | 224ms |
| *_with_gen() (after) | 202ms |
commit-graph at v5.10:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 72ms |
| *_with_gen() (before) | 37ms |
| *_with_gen() (after) | 9ms |
Note that these are only modest improvements for the case where the two
independent commits are not in the commit-graph (not until v5.10). All
algorithms get faster as more commits are indexed, which is not a
surprise. However, the cost of walking extra commits is more and more
prevalent in relative terms as more commits are indexed. Finally, the
last case allows us to jump to the minimum generation between the last
two commits (that are actually independent) so we greatly reduce the
cost in that case.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:10 +01:00
|
|
|
if (oideq(&c->object.oid, &sorted[min_gen_pos]->object.oid)) {
|
|
|
|
while (min_gen_pos < cnt - 1 &&
|
|
|
|
(sorted[min_gen_pos]->object.flags & STALE))
|
|
|
|
min_gen_pos++;
|
|
|
|
min_generation = commit_graph_generation(sorted[min_gen_pos]);
|
|
|
|
}
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
}
|
2021-02-19 13:34:09 +01:00
|
|
|
|
|
|
|
if (commit_graph_generation(c) < min_generation) {
|
|
|
|
pop_commit(&stack);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
parents = c->parents;
|
|
|
|
while (parents) {
|
|
|
|
if (!(parents->item->object.flags & STALE)) {
|
|
|
|
parents->item->object.flags |= STALE;
|
|
|
|
commit_list_insert(parents->item, &stack);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
parents = parents->next;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* pop if all parents have been visited already */
|
|
|
|
if (!parents)
|
|
|
|
pop_commit(&stack);
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
}
|
2021-02-19 13:34:09 +01:00
|
|
|
free_commit_list(stack);
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
}
|
commit-reach: stale commits may prune generation further
The remove_redundant_with_gen() algorithm performs a depth-first-search
to find commits in the 'array' list, starting at the parents of each
commit in 'array'. The result is that commits in 'array' are marked
STALE when they are reachable from another commit in 'array'.
This depth-first-search is fast when commits lie on or near the
first-parent history of the higher commits. The search terminates early
if all but one commit becomes marked STALE.
However, it is possible that there are two independent commits with high
generation number. In that case, the depth-first-search might languish
by searching in lower generations due to the fixed min_generation used
throughout the method.
With the expectation that commits with lower generation are expected to
become STALE more often, we can optimize further by increasing that
min_generation boundary upon discovery of the commit with minimum
generation.
We must first sort the commits in 'array' by generation. We cannot sort
'array' itself since it must preserve relative order among the returned
results (see revision.c:mark_redundant_parents() for an example).
This simplifies the initialization of min_generation, but it also allows
us to increase the new min_generation when we find the commit with
smallest generation remaining.
This requires more than two commits in order to test, so I used the
Linux kernel repository with a few commits that are slightly off of the
first-parent history. I timed the following command:
git merge-base --independent 2ecedd756908 d2360a398f0b \
1253935ad801 160bab43419e 0e2209629fec 1d0e16ac1a9e
The first two commits have similar generation and are near the v5.10
tag. Commit 160bab43419e is off of the first-parent history behind v5.5,
while the others are scattered somewhere reachable from v5.9. This is
designed to demonstrate the optimization, as that commit within v5.5
would normally cause a lot of extra commit walking.
Since remove_redundant_with_alg() is called only when at least one of
the input commits has a finite generation number, this algorithm is
tested with a commit-graph generated starting at a number of different
tags, the earliest being v5.5.
commit-graph at v5.5:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 864ms |
| *_with_gen() (before) | 858ms |
| *_with_gen() (after) | 810ms |
commit-graph at v5.7:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 625ms |
| *_with_gen() (before) | 572ms |
| *_with_gen() (after) | 517ms |
commit-graph at v5.9:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 268ms |
| *_with_gen() (before) | 224ms |
| *_with_gen() (after) | 202ms |
commit-graph at v5.10:
| Method | Time |
|-----------------------+-------|
| *_no_gen() | 72ms |
| *_with_gen() (before) | 37ms |
| *_with_gen() (after) | 9ms |
Note that these are only modest improvements for the case where the two
independent commits are not in the commit-graph (not until v5.10). All
algorithms get faster as more commits are indexed, which is not a
surprise. However, the cost of walking extra commits is more and more
prevalent in relative terms as more commits are indexed. Finally, the
last case allows us to jump to the minimum generation between the last
two commits (that are actually independent) so we greatly reduce the
cost in that case.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:10 +01:00
|
|
|
free(sorted);
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
|
2021-02-19 13:34:09 +01:00
|
|
|
/* clear result */
|
|
|
|
for (i = 0; i < cnt; i++)
|
|
|
|
array[i]->object.flags &= ~RESULT;
|
|
|
|
|
commit-reach: use one walk in remove_redundant()
The current implementation of remove_redundant() uses several calls to
paint_down_to_common() to determine that commits are independent of each
other. This leads to quadratic behavior when many inputs are passed to
commands such as 'git merge-base'.
For example, in the Linux kernel repository, I tested the performance
by passing all tags:
git merge-base --independent $(git for-each-ref refs/tags --format="$(refname)")
(Note: I had to delete the tags v2.6.11-tree and v2.6.11 as they do
not point to commits.)
Here is the performance improvement introduced by this change:
Before: 16.4s
After: 1.1s
This performance improvement requires the commit-graph file to be
present. We keep the old algorithm around as remove_redundant_no_gen()
and use it when generation_numbers_enabled() is false. This is similar
to other algorithms within commit-reach.c. The new algorithm is
implemented in remove_redundant_with_gen().
The basic approach is to do one commit walk instead of many. First, scan
all commits in the list and mark their _parents_ with the STALE flag.
This flag will indicate commits that are reachable from one of the
inputs, except not including themselves. Then, walk commits until
covering all commits up to the minimum generation number pushing the
STALE flag throughout.
At the end, we need to clear the STALE bit from all of the commits
we walked. We move the non-stale commits in 'array' to the beginning of
the list, and this might overwrite stale commits. However, we store an
array of commits that started the walk, and use clear_commit_marks() on
each of those starting commits. That method will walk the reachable
commits with the STALE bit and clear them all. This makes the algorithm
safe for re-entry or for other uses of those commits after this walk.
This logic is covered by tests in t6600-test-reach.sh, so the behavior
does not change. This is tested both in the case with a commit-graph and
without.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-19 13:34:07 +01:00
|
|
|
/* rearrange array */
|
|
|
|
for (i = count_non_stale = 0; i < cnt; i++) {
|
|
|
|
if (!(array[i]->object.flags & STALE))
|
|
|
|
array[count_non_stale++] = array[i];
|
|
|
|
}
|
|
|
|
|
|
|
|
/* clear marks */
|
|
|
|
clear_commit_marks_many(walk_start_nr, walk_start, STALE);
|
|
|
|
free(walk_start);
|
|
|
|
|
|
|
|
return count_non_stale;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int remove_redundant(struct repository *r, struct commit **array, int cnt)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Some commit in the array may be an ancestor of
|
|
|
|
* another commit. Move the independent commits to the
|
|
|
|
* beginning of 'array' and return their number. Callers
|
|
|
|
* should not rely upon the contents of 'array' after
|
|
|
|
* that number.
|
|
|
|
*/
|
|
|
|
if (generation_numbers_enabled(r)) {
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we have a single commit with finite generation
|
|
|
|
* number, then the _with_gen algorithm is preferred.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < cnt; i++) {
|
|
|
|
if (commit_graph_generation(array[i]) < GENERATION_NUMBER_INFINITY)
|
|
|
|
return remove_redundant_with_gen(r, array, cnt);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return remove_redundant_no_gen(r, array, cnt);
|
|
|
|
}
|
|
|
|
|
2018-11-14 01:12:54 +01:00
|
|
|
static struct commit_list *get_merge_bases_many_0(struct repository *r,
|
|
|
|
struct commit *one,
|
2018-07-20 18:33:02 +02:00
|
|
|
int n,
|
|
|
|
struct commit **twos,
|
|
|
|
int cleanup)
|
|
|
|
{
|
|
|
|
struct commit_list *list;
|
|
|
|
struct commit **rslt;
|
|
|
|
struct commit_list *result;
|
|
|
|
int cnt, i;
|
|
|
|
|
2018-11-14 01:12:54 +01:00
|
|
|
result = merge_bases_many(r, one, n, twos);
|
2018-07-20 18:33:02 +02:00
|
|
|
for (i = 0; i < n; i++) {
|
|
|
|
if (one == twos[i])
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
if (!result || !result->next) {
|
|
|
|
if (cleanup) {
|
|
|
|
clear_commit_marks(one, all_flags);
|
|
|
|
clear_commit_marks_many(n, twos, all_flags);
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* There are more than one */
|
|
|
|
cnt = commit_list_count(result);
|
2021-03-13 17:17:22 +01:00
|
|
|
CALLOC_ARRAY(rslt, cnt);
|
2018-07-20 18:33:02 +02:00
|
|
|
for (list = result, i = 0; list; list = list->next)
|
|
|
|
rslt[i++] = list->item;
|
|
|
|
free_commit_list(result);
|
|
|
|
|
|
|
|
clear_commit_marks(one, all_flags);
|
|
|
|
clear_commit_marks_many(n, twos, all_flags);
|
|
|
|
|
2018-11-14 01:12:54 +01:00
|
|
|
cnt = remove_redundant(r, rslt, cnt);
|
2018-07-20 18:33:02 +02:00
|
|
|
result = NULL;
|
|
|
|
for (i = 0; i < cnt; i++)
|
|
|
|
commit_list_insert_by_date(rslt[i], &result);
|
|
|
|
free(rslt);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2018-11-14 01:12:55 +01:00
|
|
|
struct commit_list *repo_get_merge_bases_many(struct repository *r,
|
|
|
|
struct commit *one,
|
|
|
|
int n,
|
|
|
|
struct commit **twos)
|
2018-07-20 18:33:02 +02:00
|
|
|
{
|
2018-11-14 01:12:55 +01:00
|
|
|
return get_merge_bases_many_0(r, one, n, twos, 1);
|
2018-07-20 18:33:02 +02:00
|
|
|
}
|
|
|
|
|
2018-11-14 01:12:55 +01:00
|
|
|
struct commit_list *repo_get_merge_bases_many_dirty(struct repository *r,
|
|
|
|
struct commit *one,
|
|
|
|
int n,
|
|
|
|
struct commit **twos)
|
2018-07-20 18:33:02 +02:00
|
|
|
{
|
2018-11-14 01:12:55 +01:00
|
|
|
return get_merge_bases_many_0(r, one, n, twos, 0);
|
2018-07-20 18:33:02 +02:00
|
|
|
}
|
|
|
|
|
2018-11-14 01:12:55 +01:00
|
|
|
struct commit_list *repo_get_merge_bases(struct repository *r,
|
|
|
|
struct commit *one,
|
|
|
|
struct commit *two)
|
2018-07-20 18:33:02 +02:00
|
|
|
{
|
2018-11-14 01:12:55 +01:00
|
|
|
return get_merge_bases_many_0(r, one, 1, &two, 1);
|
2018-07-20 18:33:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Is "commit" a descendant of one of the elements on the "with_commit" list?
|
|
|
|
*/
|
2020-06-23 20:42:22 +02:00
|
|
|
int repo_is_descendant_of(struct repository *r,
|
|
|
|
struct commit *commit,
|
|
|
|
struct commit_list *with_commit)
|
2018-07-20 18:33:02 +02:00
|
|
|
{
|
|
|
|
if (!with_commit)
|
|
|
|
return 1;
|
|
|
|
|
libs: use "struct repository *" argument, not "the_repository"
As can easily be seen from grepping in our sources, we had these uses
of "the_repository" in various library code in cases where the
function in question was already getting a "struct repository *"
argument. Let's use that argument instead.
Out of these changes only the changes to "cache-tree.c",
"commit-reach.c", "shallow.c" and "upload-pack.c" would have cleanly
applied before the migration away from the "repo_*()" wrapper macros
in the preceding commits.
The rest aren't new, as we'd previously implicitly refer to
"the_repository", but it's now more obvious that we were doing the
wrong thing all along, and should have used the parameter instead.
The change to change "get_index_format_default(the_repository)" in
"read-cache.c" to use the "r" variable instead should arguably have
been part of [1], or in the subsequent cleanup in [2]. Let's do it
here, as can be seen from the initial code in [3] it's not important
that we use "the_repository" there, but would prefer to always use the
current repository.
This change excludes the "the_repository" use in "upload-pack.c"'s
upload_pack_advertise(), as the in-flight [4] makes that change.
1. ee1f0c242ef (read-cache: add index.skipHash config option,
2023-01-06)
2. 6269f8eaad0 (treewide: always have a valid "index_state.repo"
member, 2023-01-17)
3. 7211b9e7534 (repo-settings: consolidate some config settings,
2019-08-13)
4. <Y/hbUsGPVNAxTdmS@coredump.intra.peff.net>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-28 15:58:58 +02:00
|
|
|
if (generation_numbers_enabled(r)) {
|
commit-reach: use can_all_from_reach
The is_descendant_of method previously used in_merge_bases() to check if
the commit can reach any of the commits in the provided list. This had
two performance problems:
1. The performance is quadratic in worst-case.
2. A single in_merge_bases() call requires walking beyond the target
commit in order to find the full set of boundary commits that may be
merge-bases.
The can_all_from_reach method avoids this quadratic behavior and can
limit the search beyond the target commits using generation numbers. It
requires a small prototype adjustment to stop using commit-date as a
cutoff, as that optimization is no longer appropriate here.
Since in_merge_bases() uses paint_down_to_common(), is_descendant_of()
naturally found cutoffs to avoid walking the entire commit graph. Since
we want to always return the correct result, we cannot use the
min_commit_date cutoff in can_all_from_reach. We then rely on generation
numbers to provide the cutoff.
Since not all repos will have a commit-graph file, nor will we always
have generation numbers computed for a commit-graph file, create a new
method, generation_numbers_enabled(), that checks for a commit-graph
file and sees if the first commit in the file has a non-zero generation
number. In the case that we do not have generation numbers, use the old
logic for is_descendant_of().
Performance was meausured on a copy of the Linux repository using the
'test-tool reach is_descendant_of' command using this input:
A:v4.9
X:v4.10
X:v4.11
X:v4.12
X:v4.13
X:v4.14
X:v4.15
X:v4.16
X:v4.17
X.v3.0
Note that this input is tailored to demonstrate the quadratic nature of
the previous method, as it will compute merge-bases for v4.9 versus all
of the later versions before checking against v4.1.
Before: 0.26 s
After: 0.21 s
Since we previously used the is_descendant_of method in the ref_newer
method, we also measured performance there using
'test-tool reach ref_newer' with this input:
A:v4.9
B:v3.19
Before: 0.10 s
After: 0.08 s
By adding a new commit with parent v3.19, we test the non-reachable case
of ref_newer:
Before: 0.09 s
After: 0.08 s
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-20 18:33:30 +02:00
|
|
|
struct commit_list *from_list = NULL;
|
|
|
|
int result;
|
|
|
|
commit_list_insert(commit, &from_list);
|
|
|
|
result = can_all_from_reach(from_list, with_commit, 0);
|
|
|
|
free_commit_list(from_list);
|
|
|
|
return result;
|
|
|
|
} else {
|
|
|
|
while (with_commit) {
|
|
|
|
struct commit *other;
|
|
|
|
|
|
|
|
other = with_commit->item;
|
|
|
|
with_commit = with_commit->next;
|
commit-reach: use fast logic in repo_in_merge_base
The repo_is_descendant_of() method is aware of the existence of the
commit-graph file. It checks for generation_numbers_enabled() before
deciding on using can_all_from_reach() or repo_in_merge_bases()
depending on the situation. The reason here is that can_all_from_reach()
uses a depth-first search that is limited by the minimum generation
number of the target commits, and that algorithm can be very slow when
generation numbers are not present. The alternative uses
paint_down_to_common() which will walk the entire merge-base boundary,
which is typically slower.
This method is used by commands like "git tag --contains" and "git
branch --contains" for very fast results when a commit-graph file
exists. Unfortunately, it is _not_ used in commands like "git merge-base
--is-ancestor" which is doing an even simpler request.
This issue was raised recently [1] with respect to a change to how
generation numbers are stored, but was also reported much earlier [2]
before commit-reach.c existed to simplify these reachability queries.
[1] https://lore.kernel.org/git/20200607195347.GA8232@szeder.dev/
[2] https://lore.kernel.org/git/87608bawoa.fsf@evledraar.gmail.com/
The root cause is that builtin/merge-base.c has a method
handle_is_ancestor() that calls in_merge_bases(), an older version of
repo_in_merge_bases(). It would be better if we have every caller to
in_merge_bases() use the logic in can_all_from_reach() when possible.
This is where things get a little tricky: repo_is_descendant_of() calls
repo_in_merge_bases() in the non-generation numbers enabled case! If we
simply update repo_in_merge_bases() to call repo_is_descendant_of()
instead of repo_in_merge_bases_many(), then we will get a recursive call
loop. Thankfully, this is caught by the test suite in the default mode
(i.e. GIT_TEST_COMMIT_GRAPH=0).
The trick, then, is to make the non-generation number case for
repo_is_descendant_of() call repo_in_merge_bases_many() directly,
skipping the non-_many version. This allows us to take advantage of this
faster code path, when possible.
The easiest way to measure the performance impact is to test the
following command on the Linux kernel repository:
git merge-base --is-ancestor <A> <B>
| A | B | Time Before | Time After |
|------|------|-------------|------------|
| v3.0 | v5.7 | 0.459s | 0.028s |
| v4.0 | v5.7 | 0.267s | 0.021s |
| v5.0 | v5.7 | 0.074s | 0.013s |
Note that each of these samples return success. The old code performed
the same operation when <A> and <B> are swapped. However,
can_all_from_reach() will return immediately if the generation numbers
show that <A> has larger generation number than <B>. Thus, the time for
the swapped case is universally 0.004s in each case.
Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reported-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-17 19:24:29 +02:00
|
|
|
if (repo_in_merge_bases_many(r, other, 1, &commit))
|
commit-reach: use can_all_from_reach
The is_descendant_of method previously used in_merge_bases() to check if
the commit can reach any of the commits in the provided list. This had
two performance problems:
1. The performance is quadratic in worst-case.
2. A single in_merge_bases() call requires walking beyond the target
commit in order to find the full set of boundary commits that may be
merge-bases.
The can_all_from_reach method avoids this quadratic behavior and can
limit the search beyond the target commits using generation numbers. It
requires a small prototype adjustment to stop using commit-date as a
cutoff, as that optimization is no longer appropriate here.
Since in_merge_bases() uses paint_down_to_common(), is_descendant_of()
naturally found cutoffs to avoid walking the entire commit graph. Since
we want to always return the correct result, we cannot use the
min_commit_date cutoff in can_all_from_reach. We then rely on generation
numbers to provide the cutoff.
Since not all repos will have a commit-graph file, nor will we always
have generation numbers computed for a commit-graph file, create a new
method, generation_numbers_enabled(), that checks for a commit-graph
file and sees if the first commit in the file has a non-zero generation
number. In the case that we do not have generation numbers, use the old
logic for is_descendant_of().
Performance was meausured on a copy of the Linux repository using the
'test-tool reach is_descendant_of' command using this input:
A:v4.9
X:v4.10
X:v4.11
X:v4.12
X:v4.13
X:v4.14
X:v4.15
X:v4.16
X:v4.17
X.v3.0
Note that this input is tailored to demonstrate the quadratic nature of
the previous method, as it will compute merge-bases for v4.9 versus all
of the later versions before checking against v4.1.
Before: 0.26 s
After: 0.21 s
Since we previously used the is_descendant_of method in the ref_newer
method, we also measured performance there using
'test-tool reach ref_newer' with this input:
A:v4.9
B:v3.19
Before: 0.10 s
After: 0.08 s
By adding a new commit with parent v3.19, we test the non-reachable case
of ref_newer:
Before: 0.09 s
After: 0.08 s
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-20 18:33:30 +02:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
2018-07-20 18:33:02 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Is "commit" an ancestor of one of the "references"?
|
|
|
|
*/
|
2018-11-14 01:12:56 +01:00
|
|
|
int repo_in_merge_bases_many(struct repository *r, struct commit *commit,
|
|
|
|
int nr_reference, struct commit **reference)
|
2018-07-20 18:33:02 +02:00
|
|
|
{
|
|
|
|
struct commit_list *bases;
|
|
|
|
int ret = 0, i;
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t generation, max_generation = GENERATION_NUMBER_ZERO;
|
2018-07-20 18:33:02 +02:00
|
|
|
|
2018-11-14 01:12:56 +01:00
|
|
|
if (repo_parse_commit(r, commit))
|
2018-07-20 18:33:02 +02:00
|
|
|
return ret;
|
|
|
|
for (i = 0; i < nr_reference; i++) {
|
2018-11-14 01:12:56 +01:00
|
|
|
if (repo_parse_commit(r, reference[i]))
|
2018-07-20 18:33:02 +02:00
|
|
|
return ret;
|
2020-06-17 11:14:11 +02:00
|
|
|
|
|
|
|
generation = commit_graph_generation(reference[i]);
|
commit-reach: fix in_merge_bases_many bug
Way back in f9b8908b (commit.c: use generation numbers for
in_merge_bases(), 2018-05-01), a heuristic was used to short-circuit
the in_merge_bases() walk. This works just fine as long as the
caller is checking only two commits, but when there are multiple,
there is a possibility that this heuristic is _very wrong_.
Some code moves since then has changed this method to
repo_in_merge_bases_many() inside commit-reach.c. The heuristic
computes the minimum generation number of the "reference" list, then
compares this number to the generation number of the "commit".
In a recent topic, a test was added that used in_merge_bases_many()
to test if a commit was reachable from a number of commits pulled
from a reflog. However, this highlighted the problem: if any of the
reference commits have a smaller generation number than the given
commit, then the walk is skipped _even if there exist some with
higher generation number_.
This heuristic is wrong! It must check the MAXIMUM generation number
of the reference commits, not the MINIMUM.
This highlights a testing gap. t6600-test-reach.sh covers many
methods in commit-reach.c, including in_merge_bases() and
get_merge_bases_many(), but since these methods either restrict to
two input commits or actually look for the full list of merge bases,
they don't check this heuristic!
Add a possible input to "test-tool reach" that tests
in_merge_bases_many() and add tests to t6600-test-reach.sh that
cover this heuristic. This includes cases for the reference commits
having generation above and below the generation of the input commit,
but also having maximum generation below the generation of the input
commit.
The fix itself is to swap min_generation with a max_generation in
repo_in_merge_bases_many().
Reported-by: Srinidhi Kaushik <shrinidhi.kaushik@gmail.com>
Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-02 16:58:56 +02:00
|
|
|
if (generation > max_generation)
|
|
|
|
max_generation = generation;
|
2018-07-20 18:33:02 +02:00
|
|
|
}
|
|
|
|
|
2020-06-17 11:14:11 +02:00
|
|
|
generation = commit_graph_generation(commit);
|
commit-reach: fix in_merge_bases_many bug
Way back in f9b8908b (commit.c: use generation numbers for
in_merge_bases(), 2018-05-01), a heuristic was used to short-circuit
the in_merge_bases() walk. This works just fine as long as the
caller is checking only two commits, but when there are multiple,
there is a possibility that this heuristic is _very wrong_.
Some code moves since then has changed this method to
repo_in_merge_bases_many() inside commit-reach.c. The heuristic
computes the minimum generation number of the "reference" list, then
compares this number to the generation number of the "commit".
In a recent topic, a test was added that used in_merge_bases_many()
to test if a commit was reachable from a number of commits pulled
from a reflog. However, this highlighted the problem: if any of the
reference commits have a smaller generation number than the given
commit, then the walk is skipped _even if there exist some with
higher generation number_.
This heuristic is wrong! It must check the MAXIMUM generation number
of the reference commits, not the MINIMUM.
This highlights a testing gap. t6600-test-reach.sh covers many
methods in commit-reach.c, including in_merge_bases() and
get_merge_bases_many(), but since these methods either restrict to
two input commits or actually look for the full list of merge bases,
they don't check this heuristic!
Add a possible input to "test-tool reach" that tests
in_merge_bases_many() and add tests to t6600-test-reach.sh that
cover this heuristic. This includes cases for the reference commits
having generation above and below the generation of the input commit,
but also having maximum generation below the generation of the input
commit.
The fix itself is to swap min_generation with a max_generation in
repo_in_merge_bases_many().
Reported-by: Srinidhi Kaushik <shrinidhi.kaushik@gmail.com>
Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-02 16:58:56 +02:00
|
|
|
if (generation > max_generation)
|
2018-07-20 18:33:02 +02:00
|
|
|
return ret;
|
|
|
|
|
2018-11-14 01:12:56 +01:00
|
|
|
bases = paint_down_to_common(r, commit,
|
2018-11-14 01:12:51 +01:00
|
|
|
nr_reference, reference,
|
2020-06-17 11:14:11 +02:00
|
|
|
generation);
|
2018-07-20 18:33:02 +02:00
|
|
|
if (commit->object.flags & PARENT2)
|
|
|
|
ret = 1;
|
|
|
|
clear_commit_marks(commit, all_flags);
|
|
|
|
clear_commit_marks_many(nr_reference, reference, all_flags);
|
|
|
|
free_commit_list(bases);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Is "commit" an ancestor of (i.e. reachable from) the "reference"?
|
|
|
|
*/
|
2018-11-14 01:12:56 +01:00
|
|
|
int repo_in_merge_bases(struct repository *r,
|
|
|
|
struct commit *commit,
|
|
|
|
struct commit *reference)
|
2018-07-20 18:33:02 +02:00
|
|
|
{
|
commit-reach: use fast logic in repo_in_merge_base
The repo_is_descendant_of() method is aware of the existence of the
commit-graph file. It checks for generation_numbers_enabled() before
deciding on using can_all_from_reach() or repo_in_merge_bases()
depending on the situation. The reason here is that can_all_from_reach()
uses a depth-first search that is limited by the minimum generation
number of the target commits, and that algorithm can be very slow when
generation numbers are not present. The alternative uses
paint_down_to_common() which will walk the entire merge-base boundary,
which is typically slower.
This method is used by commands like "git tag --contains" and "git
branch --contains" for very fast results when a commit-graph file
exists. Unfortunately, it is _not_ used in commands like "git merge-base
--is-ancestor" which is doing an even simpler request.
This issue was raised recently [1] with respect to a change to how
generation numbers are stored, but was also reported much earlier [2]
before commit-reach.c existed to simplify these reachability queries.
[1] https://lore.kernel.org/git/20200607195347.GA8232@szeder.dev/
[2] https://lore.kernel.org/git/87608bawoa.fsf@evledraar.gmail.com/
The root cause is that builtin/merge-base.c has a method
handle_is_ancestor() that calls in_merge_bases(), an older version of
repo_in_merge_bases(). It would be better if we have every caller to
in_merge_bases() use the logic in can_all_from_reach() when possible.
This is where things get a little tricky: repo_is_descendant_of() calls
repo_in_merge_bases() in the non-generation numbers enabled case! If we
simply update repo_in_merge_bases() to call repo_is_descendant_of()
instead of repo_in_merge_bases_many(), then we will get a recursive call
loop. Thankfully, this is caught by the test suite in the default mode
(i.e. GIT_TEST_COMMIT_GRAPH=0).
The trick, then, is to make the non-generation number case for
repo_is_descendant_of() call repo_in_merge_bases_many() directly,
skipping the non-_many version. This allows us to take advantage of this
faster code path, when possible.
The easiest way to measure the performance impact is to test the
following command on the Linux kernel repository:
git merge-base --is-ancestor <A> <B>
| A | B | Time Before | Time After |
|------|------|-------------|------------|
| v3.0 | v5.7 | 0.459s | 0.028s |
| v4.0 | v5.7 | 0.267s | 0.021s |
| v5.0 | v5.7 | 0.074s | 0.013s |
Note that each of these samples return success. The old code performed
the same operation when <A> and <B> are swapped. However,
can_all_from_reach() will return immediately if the generation numbers
show that <A> has larger generation number than <B>. Thus, the time for
the swapped case is universally 0.004s in each case.
Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reported-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-17 19:24:29 +02:00
|
|
|
int res;
|
|
|
|
struct commit_list *list = NULL;
|
|
|
|
struct commit_list **next = &list;
|
|
|
|
|
|
|
|
next = commit_list_append(commit, next);
|
|
|
|
res = repo_is_descendant_of(r, reference, list);
|
|
|
|
free_commit_list(list);
|
|
|
|
|
|
|
|
return res;
|
2018-07-20 18:33:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
struct commit_list *reduce_heads(struct commit_list *heads)
|
|
|
|
{
|
|
|
|
struct commit_list *p;
|
|
|
|
struct commit_list *result = NULL, **tail = &result;
|
|
|
|
struct commit **array;
|
|
|
|
int num_head, i;
|
|
|
|
|
|
|
|
if (!heads)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* Uniquify */
|
|
|
|
for (p = heads; p; p = p->next)
|
|
|
|
p->item->object.flags &= ~STALE;
|
|
|
|
for (p = heads, num_head = 0; p; p = p->next) {
|
|
|
|
if (p->item->object.flags & STALE)
|
|
|
|
continue;
|
|
|
|
p->item->object.flags |= STALE;
|
|
|
|
num_head++;
|
|
|
|
}
|
2021-03-13 17:17:22 +01:00
|
|
|
CALLOC_ARRAY(array, num_head);
|
2018-07-20 18:33:02 +02:00
|
|
|
for (p = heads, i = 0; p; p = p->next) {
|
|
|
|
if (p->item->object.flags & STALE) {
|
|
|
|
array[i++] = p->item;
|
|
|
|
p->item->object.flags &= ~STALE;
|
|
|
|
}
|
|
|
|
}
|
2018-11-14 01:12:53 +01:00
|
|
|
num_head = remove_redundant(the_repository, array, num_head);
|
2018-07-20 18:33:02 +02:00
|
|
|
for (i = 0; i < num_head; i++)
|
|
|
|
tail = &commit_list_insert(array[i], tail)->next;
|
|
|
|
free(array);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
void reduce_heads_replace(struct commit_list **heads)
|
|
|
|
{
|
|
|
|
struct commit_list *result = reduce_heads(*heads);
|
|
|
|
free_commit_list(*heads);
|
|
|
|
*heads = result;
|
|
|
|
}
|
2018-07-20 18:33:06 +02:00
|
|
|
|
|
|
|
int ref_newer(const struct object_id *new_oid, const struct object_id *old_oid)
|
|
|
|
{
|
|
|
|
struct object *o;
|
|
|
|
struct commit *old_commit, *new_commit;
|
2018-07-20 18:33:27 +02:00
|
|
|
struct commit_list *old_commit_list = NULL;
|
2020-06-19 15:13:46 +02:00
|
|
|
int ret;
|
2018-07-20 18:33:06 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Both new_commit and old_commit must be commit-ish and new_commit is descendant of
|
|
|
|
* old_commit. Otherwise we require --force.
|
|
|
|
*/
|
|
|
|
o = deref_tag(the_repository, parse_object(the_repository, old_oid),
|
|
|
|
NULL, 0);
|
|
|
|
if (!o || o->type != OBJ_COMMIT)
|
|
|
|
return 0;
|
|
|
|
old_commit = (struct commit *) o;
|
|
|
|
|
|
|
|
o = deref_tag(the_repository, parse_object(the_repository, new_oid),
|
|
|
|
NULL, 0);
|
|
|
|
if (!o || o->type != OBJ_COMMIT)
|
|
|
|
return 0;
|
|
|
|
new_commit = (struct commit *) o;
|
|
|
|
|
2023-03-28 15:58:48 +02:00
|
|
|
if (repo_parse_commit(the_repository, new_commit) < 0)
|
2018-07-20 18:33:06 +02:00
|
|
|
return 0;
|
|
|
|
|
2018-07-20 18:33:27 +02:00
|
|
|
commit_list_insert(old_commit, &old_commit_list);
|
2020-07-07 07:09:15 +02:00
|
|
|
ret = repo_is_descendant_of(the_repository,
|
2020-06-23 20:42:22 +02:00
|
|
|
new_commit, old_commit_list);
|
2020-06-19 15:13:46 +02:00
|
|
|
free_commit_list(old_commit_list);
|
|
|
|
return ret;
|
2018-07-20 18:33:06 +02:00
|
|
|
}
|
2018-07-20 18:33:08 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Mimicking the real stack, this stack lives on the heap, avoiding stack
|
|
|
|
* overflows.
|
|
|
|
*
|
|
|
|
* At each recursion step, the stack items points to the commits whose
|
|
|
|
* ancestors are to be inspected.
|
|
|
|
*/
|
|
|
|
struct contains_stack {
|
|
|
|
int nr, alloc;
|
|
|
|
struct contains_stack_entry {
|
|
|
|
struct commit *commit;
|
|
|
|
struct commit_list *parents;
|
|
|
|
} *contains_stack;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int in_commit_list(const struct commit_list *want, struct commit *c)
|
|
|
|
{
|
|
|
|
for (; want; want = want->next)
|
2018-10-02 23:19:21 +02:00
|
|
|
if (oideq(&want->item->object.oid, &c->object.oid))
|
2018-07-20 18:33:08 +02:00
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Test whether the candidate is contained in the list.
|
|
|
|
* Do not recurse to find out, though, but return -1 if inconclusive.
|
|
|
|
*/
|
|
|
|
static enum contains_result contains_test(struct commit *candidate,
|
|
|
|
const struct commit_list *want,
|
|
|
|
struct contains_cache *cache,
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t cutoff)
|
2018-07-20 18:33:08 +02:00
|
|
|
{
|
|
|
|
enum contains_result *cached = contains_cache_at(cache, candidate);
|
|
|
|
|
|
|
|
/* If we already have the answer cached, return that. */
|
|
|
|
if (*cached)
|
|
|
|
return *cached;
|
|
|
|
|
|
|
|
/* or are we it? */
|
|
|
|
if (in_commit_list(want, candidate)) {
|
|
|
|
*cached = CONTAINS_YES;
|
|
|
|
return CONTAINS_YES;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Otherwise, we don't know; prepare to recurse */
|
|
|
|
parse_commit_or_die(candidate);
|
|
|
|
|
2020-06-17 11:14:10 +02:00
|
|
|
if (commit_graph_generation(candidate) < cutoff)
|
2018-07-20 18:33:08 +02:00
|
|
|
return CONTAINS_NO;
|
|
|
|
|
|
|
|
return CONTAINS_UNKNOWN;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void push_to_contains_stack(struct commit *candidate, struct contains_stack *contains_stack)
|
|
|
|
{
|
|
|
|
ALLOC_GROW(contains_stack->contains_stack, contains_stack->nr + 1, contains_stack->alloc);
|
|
|
|
contains_stack->contains_stack[contains_stack->nr].commit = candidate;
|
|
|
|
contains_stack->contains_stack[contains_stack->nr++].parents = candidate->parents;
|
|
|
|
}
|
|
|
|
|
|
|
|
static enum contains_result contains_tag_algo(struct commit *candidate,
|
|
|
|
const struct commit_list *want,
|
|
|
|
struct contains_cache *cache)
|
|
|
|
{
|
|
|
|
struct contains_stack contains_stack = { 0, 0, NULL };
|
|
|
|
enum contains_result result;
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t cutoff = GENERATION_NUMBER_INFINITY;
|
2018-07-20 18:33:08 +02:00
|
|
|
const struct commit_list *p;
|
|
|
|
|
|
|
|
for (p = want; p; p = p->next) {
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t generation;
|
2018-07-20 18:33:08 +02:00
|
|
|
struct commit *c = p->item;
|
|
|
|
load_commit_graph_info(the_repository, c);
|
2020-06-17 11:14:11 +02:00
|
|
|
generation = commit_graph_generation(c);
|
|
|
|
if (generation < cutoff)
|
|
|
|
cutoff = generation;
|
2018-07-20 18:33:08 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
result = contains_test(candidate, want, cache, cutoff);
|
|
|
|
if (result != CONTAINS_UNKNOWN)
|
|
|
|
return result;
|
|
|
|
|
|
|
|
push_to_contains_stack(candidate, &contains_stack);
|
|
|
|
while (contains_stack.nr) {
|
|
|
|
struct contains_stack_entry *entry = &contains_stack.contains_stack[contains_stack.nr - 1];
|
|
|
|
struct commit *commit = entry->commit;
|
|
|
|
struct commit_list *parents = entry->parents;
|
|
|
|
|
|
|
|
if (!parents) {
|
|
|
|
*contains_cache_at(cache, commit) = CONTAINS_NO;
|
|
|
|
contains_stack.nr--;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* If we just popped the stack, parents->item has been marked,
|
|
|
|
* therefore contains_test will return a meaningful yes/no.
|
|
|
|
*/
|
|
|
|
else switch (contains_test(parents->item, want, cache, cutoff)) {
|
|
|
|
case CONTAINS_YES:
|
|
|
|
*contains_cache_at(cache, commit) = CONTAINS_YES;
|
|
|
|
contains_stack.nr--;
|
|
|
|
break;
|
|
|
|
case CONTAINS_NO:
|
|
|
|
entry->parents = parents->next;
|
|
|
|
break;
|
|
|
|
case CONTAINS_UNKNOWN:
|
|
|
|
push_to_contains_stack(parents->item, &contains_stack);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
free(contains_stack.contains_stack);
|
|
|
|
return contains_test(candidate, want, cache, cutoff);
|
|
|
|
}
|
|
|
|
|
|
|
|
int commit_contains(struct ref_filter *filter, struct commit *commit,
|
|
|
|
struct commit_list *list, struct contains_cache *cache)
|
|
|
|
{
|
|
|
|
if (filter->with_commit_tag_algo)
|
|
|
|
return contains_tag_algo(commit, list, cache) == CONTAINS_YES;
|
2020-06-23 20:42:22 +02:00
|
|
|
return repo_is_descendant_of(the_repository, commit, list);
|
2018-07-20 18:33:08 +02:00
|
|
|
}
|
2018-07-20 18:33:13 +02:00
|
|
|
|
|
|
|
int can_all_from_reach_with_flag(struct object_array *from,
|
|
|
|
unsigned int with_flag,
|
|
|
|
unsigned int assign_flag,
|
2018-07-20 18:33:28 +02:00
|
|
|
time_t min_commit_date,
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t min_generation)
|
2018-07-20 18:33:13 +02:00
|
|
|
{
|
2018-07-20 18:33:28 +02:00
|
|
|
struct commit **list = NULL;
|
2018-07-20 18:33:13 +02:00
|
|
|
int i;
|
2018-09-21 17:05:26 +02:00
|
|
|
int nr_commits;
|
2018-07-20 18:33:28 +02:00
|
|
|
int result = 1;
|
2018-07-20 18:33:13 +02:00
|
|
|
|
2018-07-20 18:33:28 +02:00
|
|
|
ALLOC_ARRAY(list, from->nr);
|
2018-09-21 17:05:26 +02:00
|
|
|
nr_commits = 0;
|
2018-07-20 18:33:13 +02:00
|
|
|
for (i = 0; i < from->nr; i++) {
|
2018-09-21 17:05:26 +02:00
|
|
|
struct object *from_one = from->objects[i].item;
|
2018-07-20 18:33:13 +02:00
|
|
|
|
2018-09-21 17:05:26 +02:00
|
|
|
if (!from_one || from_one->flags & assign_flag)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
from_one = deref_tag(the_repository, from_one,
|
|
|
|
"a from object", 0);
|
|
|
|
if (!from_one || from_one->type != OBJ_COMMIT) {
|
2018-09-25 15:27:41 +02:00
|
|
|
/*
|
|
|
|
* no way to tell if this is reachable by
|
2018-09-21 17:05:26 +02:00
|
|
|
* looking at the ancestry chain alone, so
|
|
|
|
* leave a note to ourselves not to worry about
|
|
|
|
* this object anymore.
|
|
|
|
*/
|
|
|
|
from->objects[i].item->flags |= assign_flag;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
list[nr_commits] = (struct commit *)from_one;
|
2023-03-28 15:58:48 +02:00
|
|
|
if (repo_parse_commit(the_repository, list[nr_commits]) ||
|
2020-06-17 11:14:10 +02:00
|
|
|
commit_graph_generation(list[nr_commits]) < min_generation) {
|
2018-09-21 17:05:26 +02:00
|
|
|
result = 0;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
nr_commits++;
|
2018-07-20 18:33:13 +02:00
|
|
|
}
|
2018-07-20 18:33:28 +02:00
|
|
|
|
2018-09-21 17:05:26 +02:00
|
|
|
QSORT(list, nr_commits, compare_commits_by_gen);
|
2018-07-20 18:33:28 +02:00
|
|
|
|
2018-09-21 17:05:26 +02:00
|
|
|
for (i = 0; i < nr_commits; i++) {
|
2018-07-20 18:33:28 +02:00
|
|
|
/* DFS from list[i] */
|
|
|
|
struct commit_list *stack = NULL;
|
|
|
|
|
|
|
|
list[i]->object.flags |= assign_flag;
|
|
|
|
commit_list_insert(list[i], &stack);
|
|
|
|
|
|
|
|
while (stack) {
|
|
|
|
struct commit_list *parent;
|
|
|
|
|
commit-reach: fix first-parent heuristic
The algorithm in can_all_from_reach_with_flags() performs a depth-
first-search, terminated by generation number, intending to use
a hueristic that "important" commits are found in the first-parent
history. This heuristic is valuable in scenarios like fetch
negotiation.
However, there is a problem! After the search finds a target commit,
it should pop all commits off the stack and mark them as "can reach".
This logic is incorrect, so the algorithm instead walks all reachable
commits above the generation-number cutoff.
The existing algorithm is still an improvement over the previous
algorithm, as the worst-case complexity went from quadratic to linear.
The performance measurement at the time was good, but not dramatic.
By fixing this heuristic, we reduce the number of walked commits.
We can also re-run the performance tests from commit 4fbcca4e
"commit-reach: make can_all_from_reach... linear".
Performance was measured on the Linux repository using
'test-tool reach can_all_from_reach'. The input included rows seeded by
tag values. The "small" case included X-rows as v4.[0-9]* and Y-rows as
v3.[0-9]*. This mimics a (very large) fetch that says "I have all major
v3 releases and want all major v4 releases." The "large" case included
X-rows as "v4.*" and Y-rows as "v3.*". This adds all release-candidate
tags to the set, which does not greatly increase the number of objects
that are considered, but does increase the number of 'from' commits,
demonstrating the quadratic nature of the previous code.
Small Case:
4fbcca4e~1: 0.85 s
4fbcca4e: 0.26 s (num_walked: 1,011,035)
HEAD: 0.14 s (num_walked: 8,601)
Large Case:
4fbcca4e~1: 24.0 s
4fbcca4e: 0.12 s (num_walked: 503,925)
HEAD: 0.06 s (num_walked: 217,243)
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-18 19:24:40 +02:00
|
|
|
if (stack->item->object.flags & (with_flag | RESULT)) {
|
2018-07-20 18:33:28 +02:00
|
|
|
pop_commit(&stack);
|
commit-reach: fix first-parent heuristic
The algorithm in can_all_from_reach_with_flags() performs a depth-
first-search, terminated by generation number, intending to use
a hueristic that "important" commits are found in the first-parent
history. This heuristic is valuable in scenarios like fetch
negotiation.
However, there is a problem! After the search finds a target commit,
it should pop all commits off the stack and mark them as "can reach".
This logic is incorrect, so the algorithm instead walks all reachable
commits above the generation-number cutoff.
The existing algorithm is still an improvement over the previous
algorithm, as the worst-case complexity went from quadratic to linear.
The performance measurement at the time was good, but not dramatic.
By fixing this heuristic, we reduce the number of walked commits.
We can also re-run the performance tests from commit 4fbcca4e
"commit-reach: make can_all_from_reach... linear".
Performance was measured on the Linux repository using
'test-tool reach can_all_from_reach'. The input included rows seeded by
tag values. The "small" case included X-rows as v4.[0-9]* and Y-rows as
v3.[0-9]*. This mimics a (very large) fetch that says "I have all major
v3 releases and want all major v4 releases." The "large" case included
X-rows as "v4.*" and Y-rows as "v3.*". This adds all release-candidate
tags to the set, which does not greatly increase the number of objects
that are considered, but does increase the number of 'from' commits,
demonstrating the quadratic nature of the previous code.
Small Case:
4fbcca4e~1: 0.85 s
4fbcca4e: 0.26 s (num_walked: 1,011,035)
HEAD: 0.14 s (num_walked: 8,601)
Large Case:
4fbcca4e~1: 24.0 s
4fbcca4e: 0.12 s (num_walked: 503,925)
HEAD: 0.06 s (num_walked: 217,243)
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-18 19:24:40 +02:00
|
|
|
if (stack)
|
|
|
|
stack->item->object.flags |= RESULT;
|
2018-07-20 18:33:28 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (parent = stack->item->parents; parent; parent = parent->next) {
|
|
|
|
if (parent->item->object.flags & (with_flag | RESULT))
|
|
|
|
stack->item->object.flags |= RESULT;
|
|
|
|
|
|
|
|
if (!(parent->item->object.flags & assign_flag)) {
|
|
|
|
parent->item->object.flags |= assign_flag;
|
|
|
|
|
2023-03-28 15:58:48 +02:00
|
|
|
if (repo_parse_commit(the_repository, parent->item) ||
|
2018-07-20 18:33:28 +02:00
|
|
|
parent->item->date < min_commit_date ||
|
2020-06-17 11:14:10 +02:00
|
|
|
commit_graph_generation(parent->item) < min_generation)
|
2018-07-20 18:33:28 +02:00
|
|
|
continue;
|
|
|
|
|
|
|
|
commit_list_insert(parent->item, &stack);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!parent)
|
|
|
|
pop_commit(&stack);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(list[i]->object.flags & (with_flag | RESULT))) {
|
|
|
|
result = 0;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
cleanup:
|
2018-09-25 15:27:41 +02:00
|
|
|
clear_commit_marks_many(nr_commits, list, RESULT | assign_flag);
|
2018-09-21 17:05:27 +02:00
|
|
|
free(list);
|
|
|
|
|
2023-02-11 12:15:26 +01:00
|
|
|
for (i = 0; i < from->nr; i++) {
|
|
|
|
struct object *from_one = from->objects[i].item;
|
|
|
|
|
|
|
|
if (from_one)
|
|
|
|
from_one->flags &= ~assign_flag;
|
|
|
|
}
|
2018-09-21 17:05:27 +02:00
|
|
|
|
2018-07-20 18:33:28 +02:00
|
|
|
return result;
|
2018-07-20 18:33:13 +02:00
|
|
|
}
|
2018-07-20 18:33:23 +02:00
|
|
|
|
|
|
|
int can_all_from_reach(struct commit_list *from, struct commit_list *to,
|
|
|
|
int cutoff_by_min_date)
|
|
|
|
{
|
|
|
|
struct object_array from_objs = OBJECT_ARRAY_INIT;
|
|
|
|
time_t min_commit_date = cutoff_by_min_date ? from->item->date : 0;
|
|
|
|
struct commit_list *from_iter = from, *to_iter = to;
|
|
|
|
int result;
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t min_generation = GENERATION_NUMBER_INFINITY;
|
2018-07-20 18:33:23 +02:00
|
|
|
|
|
|
|
while (from_iter) {
|
|
|
|
add_object_array(&from_iter->item->object, NULL, &from_objs);
|
|
|
|
|
2023-03-28 15:58:48 +02:00
|
|
|
if (!repo_parse_commit(the_repository, from_iter->item)) {
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t generation;
|
2018-07-20 18:33:23 +02:00
|
|
|
if (from_iter->item->date < min_commit_date)
|
|
|
|
min_commit_date = from_iter->item->date;
|
2018-07-20 18:33:28 +02:00
|
|
|
|
2020-06-17 11:14:11 +02:00
|
|
|
generation = commit_graph_generation(from_iter->item);
|
|
|
|
if (generation < min_generation)
|
|
|
|
min_generation = generation;
|
2018-07-20 18:33:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
from_iter = from_iter->next;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (to_iter) {
|
2023-03-28 15:58:48 +02:00
|
|
|
if (!repo_parse_commit(the_repository, to_iter->item)) {
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t generation;
|
2018-07-20 18:33:23 +02:00
|
|
|
if (to_iter->item->date < min_commit_date)
|
|
|
|
min_commit_date = to_iter->item->date;
|
2018-07-20 18:33:28 +02:00
|
|
|
|
2020-06-17 11:14:11 +02:00
|
|
|
generation = commit_graph_generation(to_iter->item);
|
|
|
|
if (generation < min_generation)
|
|
|
|
min_generation = generation;
|
2018-07-20 18:33:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
to_iter->item->object.flags |= PARENT2;
|
|
|
|
|
|
|
|
to_iter = to_iter->next;
|
|
|
|
}
|
|
|
|
|
|
|
|
result = can_all_from_reach_with_flag(&from_objs, PARENT2, PARENT1,
|
2018-07-20 18:33:28 +02:00
|
|
|
min_commit_date, min_generation);
|
2018-07-20 18:33:23 +02:00
|
|
|
|
|
|
|
while (from) {
|
|
|
|
clear_commit_marks(from->item, PARENT1);
|
|
|
|
from = from->next;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (to) {
|
|
|
|
clear_commit_marks(to->item, PARENT2);
|
|
|
|
to = to->next;
|
|
|
|
}
|
|
|
|
|
|
|
|
object_array_clear(&from_objs);
|
|
|
|
return result;
|
|
|
|
}
|
2018-11-02 14:14:45 +01:00
|
|
|
|
|
|
|
struct commit_list *get_reachable_subset(struct commit **from, int nr_from,
|
|
|
|
struct commit **to, int nr_to,
|
|
|
|
unsigned int reachable_flag)
|
|
|
|
{
|
|
|
|
struct commit **item;
|
|
|
|
struct commit *current;
|
|
|
|
struct commit_list *found_commits = NULL;
|
|
|
|
struct commit **to_last = to + nr_to;
|
|
|
|
struct commit **from_last = from + nr_from;
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t min_generation = GENERATION_NUMBER_INFINITY;
|
2018-11-02 14:14:45 +01:00
|
|
|
int num_to_find = 0;
|
|
|
|
|
|
|
|
struct prio_queue queue = { compare_commits_by_gen_then_commit_date };
|
|
|
|
|
|
|
|
for (item = to; item < to_last; item++) {
|
2021-01-16 19:11:13 +01:00
|
|
|
timestamp_t generation;
|
2018-11-02 14:14:45 +01:00
|
|
|
struct commit *c = *item;
|
|
|
|
|
2023-03-28 15:58:48 +02:00
|
|
|
repo_parse_commit(the_repository, c);
|
2020-06-17 11:14:11 +02:00
|
|
|
generation = commit_graph_generation(c);
|
|
|
|
if (generation < min_generation)
|
|
|
|
min_generation = generation;
|
2018-11-02 14:14:45 +01:00
|
|
|
|
|
|
|
if (!(c->object.flags & PARENT1)) {
|
|
|
|
c->object.flags |= PARENT1;
|
|
|
|
num_to_find++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (item = from; item < from_last; item++) {
|
|
|
|
struct commit *c = *item;
|
|
|
|
if (!(c->object.flags & PARENT2)) {
|
|
|
|
c->object.flags |= PARENT2;
|
2023-03-28 15:58:48 +02:00
|
|
|
repo_parse_commit(the_repository, c);
|
2018-11-02 14:14:45 +01:00
|
|
|
|
|
|
|
prio_queue_put(&queue, *item);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
while (num_to_find && (current = prio_queue_get(&queue)) != NULL) {
|
|
|
|
struct commit_list *parents;
|
|
|
|
|
|
|
|
if (current->object.flags & PARENT1) {
|
|
|
|
current->object.flags &= ~PARENT1;
|
|
|
|
current->object.flags |= reachable_flag;
|
|
|
|
commit_list_insert(current, &found_commits);
|
|
|
|
num_to_find--;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (parents = current->parents; parents; parents = parents->next) {
|
|
|
|
struct commit *p = parents->item;
|
|
|
|
|
2023-03-28 15:58:48 +02:00
|
|
|
repo_parse_commit(the_repository, p);
|
2018-11-02 14:14:45 +01:00
|
|
|
|
2020-06-17 11:14:10 +02:00
|
|
|
if (commit_graph_generation(p) < min_generation)
|
2018-11-02 14:14:45 +01:00
|
|
|
continue;
|
|
|
|
|
|
|
|
if (p->object.flags & PARENT2)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
p->object.flags |= PARENT2;
|
|
|
|
prio_queue_put(&queue, p);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
clear_commit_marks_many(nr_to, to, PARENT1);
|
|
|
|
clear_commit_marks_many(nr_from, from, PARENT2);
|
|
|
|
|
|
|
|
return found_commits;
|
|
|
|
}
|