"Dmitry Kakurin" [off-list ref] 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?
On 9/5/07, Junio C Hamano [off-list ref] 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?
No, from couple of my emails back:
This leads to a simple idea that mostly works:
1. when files are moved from index to filesystem, then only .gitattributes in the index is used, if it's not there == no special attributes.
2. when files are moved from filesystem to index, then only .gitattributes in filesystem is used, again if it's not there == no special attributes.
Then, in any operation, only one .gitattributes is taken into account.
This is a must-do change (IMHO).
To go one step further (again IMHO) is to eliminate workspace version
of .gitattributes all together:
We could stop here, but to me this redundancy still has some room for confusion and looks unnecessary.
Plus there is still room for unintentional abuse (by mistake).
That's why I think it's a good idea to always have only one .gitattributes (in the index).
--
- Dmitry
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]