]> git.ipfire.org Git - thirdparty/git.git/commit - commit-graph.c
commit-graph: prefer default size_mult when given zero
authorDerrick Stolee <dstolee@microsoft.com>
Thu, 2 Jan 2020 16:14:14 +0000 (16:14 +0000)
committerJunio C Hamano <gitster@pobox.com>
Thu, 2 Jan 2020 21:46:34 +0000 (13:46 -0800)
commit63020f175fe26f3250ac8d19d02ef9ee271006e5
treee81c6d335b0f3612f2520d3b0ec7f16a267129c1
parent53a06cf39b756eddfe4a2a34da93e3d04eb7b728
commit-graph: prefer default size_mult when given zero

In 50f26bd ("fetch: add fetch.writeCommitGraph config setting",
2019-09-02), the fetch builtin added the capability to write a
commit-graph using the "--split" feature. This feature creates
multiple commit-graph files, and those can merge based on a set
of "split options" including a size multiple. The default size
multiple is 2, which intends to provide a log_2 N depth of the
commit-graph chain where N is the number of commits.

However, I noticed during dogfooding that my commit-graph chains
were becoming quite large when left only to builds by 'git fetch'.
It turns out that in split_graph_merge_strategy(), we default the
size_mult variable to 2 except we override it with the context's
split_opts if they exist. In builtin/fetch.c, we create such a
split_opts, but do not populate it with values.

This problem is due to two failures:

 1. It is unclear that we can add the flag COMMIT_GRAPH_WRITE_SPLIT
    with a NULL split_opts.
 2. If we have a non-NULL split_opts, then we override the default
    values even if a zero value is given.

Correct both of these issues. First, do not override size_mult when
the options provide a zero value. Second, stop creating a split_opts
in the fetch builtin.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/fetch.c
commit-graph.c