Re: [PATCH v2] doc: make clear --assume-unchanged's user contract

["Sérgio Basto" <sergio@serjux.com>]

On Ter, 2014-12-09 at 16:44 -0800, Junio C Hamano wrote: 
> Sérgio Basto <sergio@serjux.com> 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.