git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
DKDmitry Kakurin <dmitry.kakurin@gmail.com>
Date
Sep 5, 2007, 08:31 UTC
Message-ID
<a1bbc6950709050131g397f1ef0p999681f8d13a8a42@mail.gmail.com>
In-Reply-To
<7vk5r5jzpn.fsf@gitster.siamese.dyndns.org>
On 9/5/07, Junio C Hamano <gitster@pobox.com> wrote:
Show 21 quoted lines
> "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?
No, from couple of my emails back:
Show 5 quoted lines
> 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
Previous: Junio C HamanoNext: Jan Hudec
Message 26 of 28 in “.gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.”
  1. Dmitry KakurinAug 26, 2007
  2. Junio C HamanoAug 26, 2007
  3. Dmitry KakurinAug 26, 2007
  4. Junio C HamanoAug 26, 2007
  5. Dmitry KakurinAug 26, 2007
  6. Junio C HamanoAug 26, 2007
  7. Dmitry KakurinAug 26, 2007
  8. Petr BaudisAug 26, 2007
  9. Sam VilainAug 27, 2007
  10. David KastrupAug 27, 2007
  11. Sam VilainAug 27, 2007
  12. David KastrupAug 27, 2007
  13. Johannes SchindelinAug 27, 2007
  14. Johannes SchindelinAug 26, 2007
  15. martin f krafftAug 27, 2007
  16. Sergio CallegariAug 27, 2007
  17. David KastrupAug 27, 2007
  18. Petr BaudisAug 27, 2007
  19. Sergio CallegariAug 27, 2007
  20. Sergio CallegariAug 27, 2007
  21. Jan HudecSep 4, 2007
  22. .gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc.Dmitry Kakurin, Aug 27, 2007
  23. Jan HudecSep 4, 2007
  24. Dmitry KakurinSep 5, 2007
  25. Junio C HamanoSep 5, 2007
  26. Dmitry KakurinSep 5, 2007
  27. Jan HudecSep 5, 2007
  28. Jan HudecSep 4, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.