git/commit-graph.c, branch v2.24.2

Merge branch 'ds/commit-graph-on-fetch'

2019-11-04T04:33:06Z

Regression fix. * ds/commit-graph-on-fetch: commit-graph: fix writing first commit-graph during fetch t5510-fetch.sh: demonstrate fetch.writeCommitGraph bug

commit-graph: fix writing first commit-graph during fetch

2019-10-25T02:19:16Z

The previous commit includes a failing test for an issue around fetch.writeCommitGraph and fetching in a repo with a submodule. Here, we fix that bug and set the test to "test_expect_success". The problem arises with this set of commands when the remote repo at has a submodule. Note that --recurse-submodules is not needed to demonstrate the bug. $ git clone test $ cd test $ git -c fetch.writeCommitGraph=true fetch origin Computing commit graph generation numbers: 100% (12/12), done. BUG: commit-graph.c:886: missing parent for commit Aborted (core dumped) As an initial fix, I converted the code in builtin/fetch.c that calls write_commit_graph_reachable() to instead launch a "git commit-graph write --reachable --split" process. That code worked, but is not how we want the feature to work long-term. That test did demonstrate that the issue must be something to do with internal state of the 'git fetch' process. The write_commit_graph() method in commit-graph.c ensures the commits we plan to write are "closed under reachability" using close_reachable(). This method walks from the input commits, and uses the UNINTERESTING flag to mark which commits have already been visited. This allows the walk to take O(N) time, where N is the number of commits, instead of O(P) time, where P is the number of paths. (The number of paths can be exponential in the number of commits.) However, the UNINTERESTING flag is used in lots of places in the codebase. This flag usually means some barrier to stop a commit walk, such as in revision-walking to compare histories. It is not often cleared after the walk completes because the starting points of those walks do not have the UNINTERESTING flag, and clear_commit_marks() would stop immediately. This is happening during a 'git fetch' call with a remote. The fetch negotiation is comparing the remote refs with the local refs and marking some commits as UNINTERESTING. I tested running clear_commit_marks_many() to clear the UNINTERESTING flag inside close_reachable(), but the tips did not have the flag, so that did nothing. It turns out that the calculate_changed_submodule_paths() method is at fault. Thanks, Peff, for pointing out this detail! More specifically, for each submodule, the collect_changed_submodules() runs a revision walk to essentially do file-history on the list of submodules. That revision walk marks commits UNININTERESTING if they are simplified away by not changing the submodule. Instead, I finally arrived on the conclusion that I should use a flag that is not used in any other part of the code. In commit-reach.c, a number of flags were defined for commit walk algorithms. The REACHABLE flag seemed like it made the most sense, and it seems it was not actually used in the file. The REACHABLE flag was used in early versions of commit-reach.c, but was removed by 4fbcca4 (commit-reach: make can_all_from_reach... linear, 2018-07-20). Add the REACHABLE flag to commit-graph.c and use it instead of UNINTERESTING in close_reachable(). This fixes the bug in manual testing. Reported-by: Johannes Schindelin Helped-by: Jeff King Helped-by: Szeder Gábor Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

Merge branch 'ah/cleanups'

2019-10-09T05:01:00Z

Miscellaneous code clean-ups. * ah/cleanups: git_mkstemps_mode(): replace magic numbers with computed value wrapper: use a loop instead of repetitive statements diffcore-break: use a goto instead of a redundant if statement commit-graph: remove a duplicate assignment

Merge branch 'tb/commit-graph-harden'

2019-10-07T02:32:58Z

The code to parse and use the commit-graph file has been made more robust against corrupted input. * tb/commit-graph-harden: commit-graph.c: handle corrupt/missing trees commit-graph.c: handle commit parsing errors t/t5318: introduce failing 'git commit-graph write' tests

Merge branch 'gs/commit-graph-progress'

2019-10-07T02:32:57Z

* gs/commit-graph-progress: commit-graph: add --[no-]progress to write and verify

Merge branch 'rs/commit-graph-use-list-count'

2019-10-07T02:32:57Z

Code cleanup. * rs/commit-graph-use-list-count: commit-graph: use commit_list_count()

Merge branch 'jk/disable-commit-graph-during-upload-pack'

2019-10-07T02:32:55Z

The "upload-pack" (the counterpart of "git fetch") needs to disable commit-graph when responding to a shallow clone/fetch request, but the way this was done made Git panic, which has been corrected. * jk/disable-commit-graph-during-upload-pack: upload-pack: disable commit graph more gently for shallow traversal commit-graph: bump DIE_ON_LOAD check to actual load-time

Merge branch 'jk/commit-graph-cleanup'

2019-10-07T02:32:55Z

A pair of small fixups to "git commit-graph" have been applied. * jk/commit-graph-cleanup: commit-graph: turn off save_commit_buffer commit-graph: don't show progress percentages while expanding reachable commits

commit-graph: remove a duplicate assignment

2019-10-02T06:04:16Z

Leave the variable 'g' uninitialized before it is set just before its first use in front of a loop, which is a much more appropriate place to indicate what it is used for. Also initialize the variable 'num_commits' just before the loop instead of at the beginning of the function for the same reason. Reviewed-by: Derrick Stolee Signed-off-by: Alex Henrie Signed-off-by: Junio C Hamano

commit-graph: add --[no-]progress to write and verify

2019-09-18T21:23:09Z

Add --[no-]progress to git commit-graph write and verify. The progress feature was introduced in 7b0f229 ("commit-graph write: add progress output", 2018-09-17) but the ability to opt-out was overlooked. Signed-off-by: Garima Singh Signed-off-by: Junio C Hamano