Derrick Stolee [off-list ref] writes:
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?
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).
quoted
- is there configuration or a patch we can roll out to help affected
users recover from this state?
If you are willing, then take v2 of this series and follow through by
clearing the commit-graph files of affected users. Note that you can
be proactive using `git commit-graph verify` to see who needs rewrites.
FYI, today's 368b6599 (Merge branch 'ds/commit-graph-genno-fix' into
jch, 2021-02-01) has this stuff.
On 2/2/2021 9:06 PM, Junio C Hamano wrote:
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?
In this case, that won't be necessary since they are using a
split commit-graph. However, the following is what I do to
be extra sure:
rm -rf .git/objects/info/commit-graph*
Deletes the singleton file and the directory.
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).
I just like to focus on the reachable commits starting at refs
instead of scanning all packed objects to see which are commits
or not.
Thanks,
-stolee
On Tue, Feb 02, 2021 at 06:06:51PM -0800, Junio C Hamano wrote:
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.