On Wed, Sep 05, 2007 at 01:14:44 -0700, Junio C Hamano wrote:
> "Dmitry Kakurin" <dmitry.kakurin@gmail.com> writes:
> 
> > I assert that since index does not have .gitattributes the one from
> > local directory should not be used.
> >
> > Think about dedicated build machine scenario: I have a machine that
> > always does sync + build. After every sync the local directory should
> > always be identical to what-was-committed.
> 
> Thinking about the reason _why_ .gitattributes may be updated,
> one would notice that it is because somebody did this command
> sequence:
> 
> 	git checkout		;# now work tree is clean
> 	edit .gitattributes	;# modify the attributes of a file
> 	edit file		;# edit the file attributes talks about
> 	git add file		;# this can be affected by .gitattributes
> 	git add .gitattributes	;# this is changed in the same commit
> 	git commit
> 
> Now, should we always take .gitattributes from the index?

Yes, they should:

$ git checkout
$ edit .gitattributes
$ edit file
$ git add file
$ git commit ;# this does NOT have the changes to .gitattributes

the above case is a user error that can (at some cost) be detected:

$ git checkout
$ edit .gitattributes
$ edit file
$ git add file
$ git add .gitattributes
Warning! Changes to gitattributes affects handling of files scheduled for
commit. Please add following files again before commit:
  file
$

It would be possible to special-case .gitattributes in add to:
 - do diff between the old and new value of .gitattributes in index,
 - list files changed in index compared to HEAD,
 - match each of them to all patterns in the diff,
 - if any matches, print the warning and list of matches.
It might be even possible to actually inspect the changes and apply those
that can be automatically (and not ask user to re-add), but some filters
loose information, so user interaction is needed to add good version.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>