Re: git status always modifies index?

From: Jeff King <peff@peff.net>
Date: Nov 27, 2017, 06:12 UTC
Message-ID: <20171127061257.GB1247@sigill>
In-Reply-To: <xmqq7euch7jb.fsf@gitster.mtv.corp.google.com>

On Mon, Nov 27, 2017 at 09:47:20AM +0900, Junio C Hamano wrote:

Show 9 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > I'm not sure I agree. Lockless writes are actually fine for the original
> > use case of --no-optional-locks (which is a process for the same user
> > that just happens to run in the background).
> 
> The phrase "lockless write" scares me---it sounds as if you
> overwrite the index file no matter what other people (including
> another instance of yourself) are doing to it.

Ick, no, that would be quite bad. ;)

I only meant that if we "somehow" had a way in the future to update the stat cache without affecting the other parts of the index, and without causing lock contention that causes other readers to barf, it could be triggered even under this option.

That would be quite different from the current index and stat-cache design, and I have no plans in that area.

Writes to the object database _are_ lockless now (it is OK if two writers collide, because they are by definition writing the same data). And I wouldn't expect them to be affected by --no-optional-locks. I think elsewhere in the thread you mentioned writing out trees for cache-tree, which seems like a plausible example. Usually there's not much point if you're not going to write out the index with the new cache-tree entries, too. But I could see a program wanting to convert the index into a tree in order to speed up a series of tree-to-index diffs within a single program.

This is all pretty hypothetical, though.

-Peff