On Wed, Nov 16, 2016 at 10:58:30AM -0800, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > I suspect the issue is that read-tree populates the cache-tree index > > extension, and then write-tree omits the object write before it even > > gets to write_sha1_file(). > > Wait a minute. The entries in the index and trees in the cache-tree > are root of "still in use" traversal for the purpose of pruning, > which makes the "something like this" patch unnecessary for the real > index file. > > And for temporary index files that is kept for 6 months, touching > tree objects that cache-tree references is irrelevant---the blobs > recorded in the "list of objects" part of the index will go stale, > which is a lot more problematic.
I think the case that is helped here is somebody who runs "git write-tree" and expects that the timestamp on those trees is fresh. So even more a briefly used index, like: export GIT_INDEX_FILE=/tmp/foo git read-tree ... git write-tree rm -f $GIT_INDEX_FILE we'd expect that a "git gc" which runs immediately after would see those trees as recent and avoid pruning them (and transitively, any blobs that are reachable from the trees). But I don't think that write-tree actually freshens them (it sees "oh, we already have these; there is nothing to write"). I could actually see an argument that the read-tree operation should freshen the blobs themselves (because we know those blobs are now in active use, and probably shouldn't be pruned), but I am not sure I agree there. If only because it is weird that an operation which is otherwise read-only with respect to the repository would modify the object database. -Peff
