From: "Junio C Hamano" <gits...@pobox.com>
Sérgio Basto <ser...@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 <j...@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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
