Re: [PATCH v2 2/6] commit-graph: always parse before commit_graph_data_at()

SZEDER Gábor [off-list ref] writes:

On Tue, Feb 02, 2021 at 06:06:51PM -0800, Junio C Hamano wrote:

quoted

Derrick Stolee [off-list ref] writes:

quoted

quoted

- what is the recommended way to recover from this state?  "git fsck"
  shows the repositories to have no problems.  "git help commit-graph"
  doesn't show a command for users to use; is
  `rm -fr .git/objects/info/commit-graphs/` the recommended recovery
  command?

"rm -f .git/objects/info/commit-graph" as well, no?

quoted

That, followed by `git commit-graph write --reachable [--changed-paths]`
depending on what they want.

Just out of curiosity, how important is "--reachable"?  It only
traverses from the tips of refs and unlike fsck and repack, not from
reflog entries (or the index for that matter, but that shouldn't
make much difference as there is no _commit_ in the index).

Scanning all objects in all packfiles is a very inefficient way to
find the commits to be recorded in the commit-graph, and depending on
the repository's shape and size can have several times higher runtime
and memory footprint.

But wouldn't it make the resulting graph file not very useful for
the purpose of say deciding what object to pack when running "gc" or
"repack" or "prune"?  The fact that it ignores the index and the reflog
entries as roots of traversal with "--reachable" bothers me.

On 2/7/2021 3:12 PM, Junio C Hamano wrote:

SZEDER Gábor [off-list ref] writes:

quoted

Scanning all objects in all packfiles is a very inefficient way to
find the commits to be recorded in the commit-graph, and depending on
the repository's shape and size can have several times higher runtime
and memory footprint.

But wouldn't it make the resulting graph file not very useful for
the purpose of say deciding what object to pack when running "gc" or
"repack" or "prune"?  The fact that it ignores the index and the reflog
entries as roots of traversal with "--reachable" bothers me.

The reflog _might_ have something of value there, but the hope is
that very few commits are actually being force-pushed away. The focus
is to prioritize the deep history, and it would definitely be an
anti-pattern if the commits in the reflog are so numerous that they
must be tracked by the commit-graph. Of course, skipping the --reachable
option enables a way to gather these commits as necessary.

The index won't have commit oids that matter (yes, for submodules they
will exist, but those are not commits for the super repo).

Thanks,
-Stolee