Sérgio Basto <sergio@xxxxxxxxxx> writes: > Also don't understand why --assumed-untracked shouldn't deal with > changed files instead fallback in "the user promises not to change the > file" and sometimes works others not. > > Also if this is the contract when a file is different from commit, > should warning the user that is not in contract (modify files that are > assumed-untracked ) Unfortunately, that is not even possible in the case where assume-untracked is meant to be used without breaking the use case it was invented to support. The user flips the bit so that Git does not have to traverse the working tree to run lstat(2) on all of them in order to see if some have changes relative to the index. If we cannot trust that bit and need to verify, how would we do that? Think. Yes, by running lstat(2) on these files that the user promised not to touch. That just defeats the sole objective the feature was invented for in the first place. Having said all that, I know what you wish to have, and I am not fundamentally opposed to a change to add a new feature to order Git to pretend that changes that may exist in the working tree are not there. It's just that assume-unchanged bit is not that. It is a way to allow Git that it can assume the files in the working tree are not changed. It is a permission, not a command. This is a tangent, but somebody may want to check the "Git will fail (gracefully)" bit in the documentation Philip's documentation patch did not remove. Such a detection is not absolutely necessary, and the paragraph may be describing a wishful thinking by somebody who misunderstood --assume-unchanged with a cursory observation of what happened for limited test cases back when the documentation was added, in which case that paragraph may also want to go. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html