Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc.

On Wed, Sep 05, 2007 at 01:14:44 -0700, Junio C Hamano wrote:

"Dmitry Kakurin" [off-list ref] writes:

quoted

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 [off-list ref]