Re: bug report on update-index --assume-unchanged

From: "Junio C Hamano" <redacted>

Sérgio Basto [off-list ref] writes:

quoted

On Sex, 2014-12-05 at 17:52 +0700, Duy Nguyen wrote:

quoted

On Fri, Dec 5, 2014 at 1:55 PM, Johannes Sixt [off-list ref] wrote:

quoted

Actually, it's a user error. When you set --assume-unchanged, then
you give
a promise to git that you do not change the files, and git does
not have to
check itself whether there is a change.

But since you did not keep your promise, you get what you deserve.
;-)

No, I marked with assume-unchanged *after* change the file , and not
before. Else don't see what is the point of assume-unchanged if you
really don't change the file.

That "unchanged" is relative to what is in the index.

Your promise is "these paths I will not modify" and in return you
gain performance in "git status" as the promise allows Git not to
check with lstat() if the files in the workng tree was modified and
instead assume that you didn't change them.  That is the point of
assume-unchanged bit.

If however you did something that made Git notice that you changed
these paths marked with assume-unchanged bit anyway, then Git will,
well, notice that they are not "unchanged" as you promised.

The problem here is that there is no guidance on what those actions are
that may make git 'notice'. The man page git-update-index isn't as clear
as it could be. Using --really-refresh being one option that would make
git notice, but I wouldn't know when that is used.

Part of the implied question is why "git commit ." would notice when
when "git commit -a" didn't appear to. So it's unclear as to what the user should have expected.

(Note, I don't use assume-unchanged myself so this is more about supporting the user/manual clarification. It is mentioned moderately often on stackoverflow etc.)

--
Philip