On Ter, 2014-12-09 at 16:44 -0800, Junio C Hamano wrote: > 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. OK, but when we do: git --assumed-untracked <file> and file is already modified. we could do an warning . May also should mention in documentation that --assumed-untracked is not to deal with "local versions of tracked config files in git" (if you don't) Meanwhile I read https://gist.github.com/canton7/1423106 I adopt https://gist.github.com/canton7/1423106#if-you-cant-modify-your-application item 1 Thanks for your patience > 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. > > > > > > -- Sérgio M. B. -- 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