Re: Protecting old temporary objects being reused from concurrent "git gc"?

From: Jeff King <peff@peff.net>
Date: Nov 17, 2016, 01:04 UTC
Message-ID: <20161117010449.6k3cwo3njvrid4jy@sigill.intra.peff.net>
In-Reply-To: <xmqq1sybqmjt.fsf@gitster.mtv.corp.google.com>

On Wed, Nov 16, 2016 at 10:58:30AM -0800, Junio C Hamano wrote:

Show 15 quoted lines

> Jeff King <peff@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