Jeff King <p...@peff.net> writes:
> There are some calculations that git makes repeatedly, even
> though the results are invariant for a certain input (e.g.,
> the patch-id of a certain commit). We can make a space/time
> tradeoff by caching these on disk between runs.
> Even though these may be immutable for a certain commit, we
> don't want to directly store the results in the commit
> objects themselves, for a few reasons:
> 1. They are not necessarily used by all algorithms, so
> bloating the commit object might slow down other
> 2. Because they can be calculated from the existing
> commits, they are redundant with the existing
> information. Thus they are an implementation detail of
> our current algorithms, and should not be cast in stone
> by including them in the commit sha1.
> 3. They may only be immutable under a certain set of
> conditions (e.g., which grafts or replace refs we are
> using). Keeping the storage external means we can
> invalidate and regenerate the cache whenever those
> conditions change.
4. The algorithm used to compute such values could improve over
time. The same advantage argument as 3 applies to this case.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html