diff options
author | Derrick Stolee <dstolee@microsoft.com> | 2020-10-09 20:53:52 +0000 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2020-10-09 14:16:32 -0700 |
commit | 85102ac71b98466eaa2b9b5a568c3a1de736202d (patch) | |
tree | d08e8527f9d4693432b997613f55693ae7bcbce5 /mergetools/deltawalker | |
parent | commit-graph: ignore duplicates when merging layers (diff) | |
download | tgif-85102ac71b98466eaa2b9b5a568c3a1de736202d.tar.xz |
commit-graph: don't write commit-graph when disabled
The core.commitGraph config setting can be set to 'false' to prevent
parsing commits from the commit-graph file(s). This causes an issue when
trying to write with "--split" which needs to distinguish between
commits that are in the existing commit-graph layers and commits that
are not. The existing mechanism uses parse_commit() and follows by
checking if there is a 'graph_pos' that shows the commit was parsed from
the commit-graph file.
When core.commitGraph=false, we do not parse the commits from the
commit-graph and 'graph_pos' indicates that no commits are in the
existing file. The --split logic moves forward creating a new layer on
top that holds all reachable commits, then possibly merges down into
those layers, resulting in duplicate commits. The previous change makes
that merging process more robust to such a situation in case it happens
in the written commit-graph data.
The easy answer here is to avoid writing a commit-graph if reading the
commit-graph is disabled. Since the resulting commit-graph will would not
be read by subsequent Git processes. This is more natural than forcing
core.commitGraph to be true for the 'write' process.
Reported-by: Thomas Braun <thomas.braun@virtuell-zuhause.de>
Helped-by: Jeff King <peff@peff.net>
Helped-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'mergetools/deltawalker')
0 files changed, 0 insertions, 0 deletions