Taylor Blau [off-list ref] writes:
Thinking aloud, I'm not totally sure that we should be exposing "git
commit-graph clear" to users. The only time that you'd want to run this
is if you were trying to remove a corrupted commit-graph, so I'd rather
see guidance on how to do that safely show up in
Documentation/git-commit-graph.txt.
On the other hand, now I'm encouraging running "rm -fr
$GIT_DIR/objects/info/commit-graph*", which feels dangerous.
True.
As this is, like pack .idx file, supposed to be "precomputed cached
data that can be fully recreated using primary information" [*], I
am perfectly fine to say "commit-graph may have unexplored corners,
and when you hit a BUG(), you can safely use 'commit-graph clear'
and recreate it from scratch, or operate without it if you feel you
do not yet want to trust your data to it for now." Giving safer and
easier way to opt out for those who need to get today's release
done, with enough performance incentive to re-enable it when the
crunch is over, would be an honest thing to do, I would think.
Side note: the index file also used to be considered to hold
such cached data, that can be recreated from the working
tree data and the tip commit. We no longer treat it that
way, though.
Somewhere in the middle would be something like:
git -c core.commitGraph=false commit-graph write --reachable
I am a bit worried about the thinking along this line, because it
gives the users an impression that there is no escaping from
trusting commit-graph---the one that was created from scratch is
bug-free and they only need to be cautious about incrementals.
But (1) we do not know that, and (2) it is an unconvincing message
to somebody who just got hit by a BUG().
which would disable reading existing commit-graph files. Since
85102ac71b (commit-graph: don't write commit-graph when disabled,
2020-10-09), that causes us to exit immediately.
Meaning the three command sequence
git commit-graph clear
git commit-graph write --reachable
git config core.commitGraph false
to force a clean build of a graph and forbid further updates until
the bug is squashed??? But should't core.commitGraph forbid reading
and using the data in the existing files, too? In which case, shouldn't
it be equivalent to "git commit-graph clear"?
I think that reverting that patch and advertising setting
'core.commitGraph=false' in the documentation makes the most sense.
On Wed, Feb 03, 2021 at 10:41:08AM -0800, Junio C Hamano wrote:
Taylor Blau [off-list ref] writes:
quoted
Thinking aloud, I'm not totally sure that we should be exposing "git
commit-graph clear" to users. The only time that you'd want to run this
is if you were trying to remove a corrupted commit-graph, so I'd rather
see guidance on how to do that safely show up in
Documentation/git-commit-graph.txt.
On the other hand, now I'm encouraging running "rm -fr
$GIT_DIR/objects/info/commit-graph*", which feels dangerous.
True.
As this is, like pack .idx file, supposed to be "precomputed cached
data that can be fully recreated using primary information" [*], I
am perfectly fine to say "commit-graph may have unexplored corners,
and when you hit a BUG(), you can safely use 'commit-graph clear'
and recreate it from scratch, or operate without it if you feel you
do not yet want to trust your data to it for now." Giving safer and
easier way to opt out for those who need to get today's release
done, with enough performance incentive to re-enable it when the
crunch is over, would be an honest thing to do, I would think.
Side note: the index file also used to be considered to hold
such cached data, that can be recreated from the working
tree data and the tip commit. We no longer treat it that
way, though.
quoted
Somewhere in the middle would be something like:
git -c core.commitGraph=false commit-graph write --reachable
I am a bit worried about the thinking along this line, because it
gives the users an impression that there is no escaping from
trusting commit-graph---the one that was created from scratch is
bug-free and they only need to be cautious about incrementals.
But (1) we do not know that, and (2) it is an unconvincing message
to somebody who just got hit by a BUG().
This is a convincing counter-point to my proposal. Yeah, I agree that we
shouldn't be advertising that commit-graph is completely trustworthy.
quoted
which would disable reading existing commit-graph files. Since
85102ac71b (commit-graph: don't write commit-graph when disabled,
2020-10-09), that causes us to exit immediately.
Meaning the three command sequence
git commit-graph clear
git commit-graph write --reachable
git config core.commitGraph false
to force a clean build of a graph and forbid further updates until
the bug is squashed??? But should't core.commitGraph forbid reading
and using the data in the existing files, too? In which case, shouldn't
it be equivalent to "git commit-graph clear"?
I think we may be saying the same thing. I was suggesting that if we
reverted 85102ac71b, that 'git -c core.commitGraph=false commit-graph
write ...' would rewrite your commit-graph from scratch (without opening
up existing ones and propagating corruption).
So I was saying that that *would* be a viable "git commit-grpah clear"
(if 85102ac71b were reverted).
Thanks,
Taylor