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

["Philip Oakley" <philipoakley@iee.org>]

From: "Junio C Hamano" <gitster@pobox.com>
> Sérgio Basto <sergio@serjux.com> writes:
>
>
>> On Sex, 2014-12-05 at 17:52 +0700, Duy Nguyen wrote:
>>> On Fri, Dec 5, 2014 at 1:55 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>>> > 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