Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > When reset_repository_shallow() is called, Git clears its cache of > shallow information, so that if shallow information is re-requested, Git > will read fresh data from disk instead of reusing its stale cached data. > However, the cache of commit grafts is not likewise cleared, even though > there are commit grafts created from shallow information. > > This means that if on-disk shallow information were to be updated and > then a commit-graft-using codepath were run (for example, a revision > walk), Git would be using stale commit graft information. This can be > seen from the test in this patch, in which Git performs a revision walk > (to check for changed submodules) after a fetch with --update-shallow. > > Therefore, clear the cache of commit grafts whenever > reset_repository_shallow() is called. Because this helper function resets not just grafts_nr, but commit_graft_prepared member, the next time prepare_commit_graft() is called, we'd recover the grafts (not derived from shallows, but read locally from "info/grafts") from the file, too, which makes it sound right ;-) And the implementation looks quite straight-forward. Will queue. Thanks.
