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

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

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.

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

On Sex, 2014-12-05 at 10:30 -0800, Junio C Hamano wrote:

Your promise is "these paths I will not modify" and in return you
gain performance in "git status"

yeah  so  --assume-unchanged is for administrators of git , like I write
I change first  and --assume-unchanged after and never change it
again . 
But if it is a tool for administration of git , I don't what to say ...
put it in a gitadmin command . 

I hate git and this is one one the reason . 

-- 
Sérgio M. B.

On Sex, 2014-12-05 at 20:48 +0000, Philip Oakley wrote:

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.

I agree with this sentence, this is a bug because:

git commit -a ( and -a means all ) is incoherent with "git commit ."
This is stupid because when I want commit part of the tree, commit
includes one file that is not included when I say to commit all . 
So maybe you should fix, git commit -a to be coherent . 

(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.)

yeap  

Sorry I don't have time to read all messages in thread , 
but I'm going to test git with the patch suggest in this thread , at
least, I solve "my" problem for some time ... 

Thanks,  
-- 
Sérgio M. B.

From: "Sérgio Basto" <redacted>
[..]

quoted

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.

I agree with this sentence, this is a bug because:

git commit -a ( and -a means all ) is incoherent with "git commit ."
This is stupid because when I want commit part of the tree, commit
includes one file that is not included when I say to commit all .
So maybe you should fix, git commit -a to be coherent .

Ultimately this (-a vs '.' with --assume-unchanged) is not a 'bug', 
because it does as planned. However the documenation is 'wrong' or at 
least misguides many readers.

Thank you for bring it to the list's attention.
[..]

Sorry I don't have time to read all messages in thread ,
but I'm going to test git with the patch suggest in this thread , at
least, I solve "my" problem for some time ...

My patch, and Junio's 'squash' are to correct the documentation, and 
especially remove the line about it having an "ignore" capability, which 
is a promise not kept (your -a vs '.' !).

I'll be updating the documenation patch today for review, though that 
doesn't solve the wider problem of:
    - 'how to temporarily ignore changes to a tracked file'.
--
Philip