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

On Wed, Nov 16, 2016 at 05:35:47PM -0800, Junio C Hamano wrote: > OK, here is what I have queued. > > -- >8 -- > Subject: cache-tree: make sure to "touch" tree objects the cache-tree records > > The cache_tree_fully_valid() function is called by callers that want > to know if they need to call

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

Jeff King writes: > 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

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

On Wed, Nov 16, 2016 at 10:58:30AM -0800, Junio C Hamano wrote: > Jeff King 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

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

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

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

Jeff King writes: > ... I notice there is > a return very early on in update_one() when has_sha1_file() matches, and > it seems like that would trigger in some interesting cases, too. Yeah, I missed that. It says "we were asked to update one cache_tree that corresponds to this

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

On Tue, Nov 15, 2016 at 12:01:35PM -0800, Junio C Hamano wrote: > Jeff King 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(). The solution is

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

Jeff King 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(). The solution is that it should probably be > calling one of the freshen() functions

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

On Tue, 2016-11-15 at 12:40 -0500, Jeff King wrote: > On Tue, Nov 15, 2016 at 12:33:04PM -0500, Matt McCutchen wrote: > > > > > On Tue, 2016-11-15 at 12:06 -0500, Jeff King wrote: > > > > > >  - when an object write is optimized out because we already have the > > >    object, git will update

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

On Tue, Nov 15, 2016 at 12:33:04PM -0500, Matt McCutchen wrote: > On Tue, 2016-11-15 at 12:06 -0500, Jeff King wrote: > >  - when an object write is optimized out because we already have the > >    object, git will update the mtime on the file (loose object or > >    packfile) to freshen it > >

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

On Tue, 2016-11-15 at 12:06 -0500, Jeff King wrote: >  - when an object write is optimized out because we already have the >    object, git will update the mtime on the file (loose object or >    packfile) to freshen it FWIW, I am not seeing this happen when I do "git read-tree --prefix" followed

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

On Tue, Nov 15, 2016 at 09:13:14AM -0500, Matt McCutchen wrote: > I want to change this to something that won't leave an inconsistent > state if interrupted.  I've written code for this kind of thing before > that sets GIT_INDEX_FILE and uses a temporary index file and "git > write-tree".  But I

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

The Braid subproject management tool stores the subproject content in the main tree and is able to switch to a different upstream revision of a subproject by doing the equivalent of "git read-tree -m" on the superproject tree and the two upstream trees.  The tricky part is preparing temporary