Re: update-index --really-refresh unsets assume-unchanged bit

From: Clemens Buchacher <drizzd@aon.at>
Date: May 5, 2010, 15:44 UTC
Message-ID: <20100505154459.GA24447@localhost>
In-Reply-To: <7v39y7mglb.fsf@alter.siamese.dyndns.org>

On Tue, May 04, 2010 at 03:45:20PM -0700, Junio C Hamano wrote:

Show 8 quoted lines

> Clemens Buchacher <drizzd@aon.at> writes:
> 
> > On the contrary. I _want_ git to assume the file is unchanged, even though I
> > know it changed. This is an intended and documented use case (from the
> > git-update-index manpage):
> 
> The intended use of *really* one is to ignore the assume unchanged bit and
> make the bit reflect reality.

Yes, and right below the part you are quoting I explained why this is not what it does either.

Show 7 quoted lines

> The bit was originally invented back when
> the machinery was too lstat(2) heavy so that people on slow filesystems
> can say "I haven't changed these paths, and I promise I won't, so you can
> trust this and assume that the working tree file exactly matches what is
> recorded in the index."  Obviously we needed to give such users an way to
> tell git that they broke their promise, and that is what *really* refresh
> meant to give.

Yes, but after the index is refreshed, the file is now, again, unchanged. Yet, the assume-unchanged bit is unset.

But there is no reason presume that the user will break their promise again in the future. If they plan to do so, they can always use git update-index --no-assume-unchanged.

Show 5 quoted lines

> Note that the promise is _different_ from telling "I may or may not have
> changed the work tree files, but don't bother telling me that I did".  The
> promise you make by "assume unchanged" bit allows git to read from the
> working tree file when it needs the contents of blob recorded in the index
> and the bit is set, as you promised that you will never change it.

And in what case does git do that? I can only find commands which read from the object store and not from the work tree. This would also break the "ignore changes to tracked files" use case.

Clemens