12

Considering I have *.pdf files in both my .gitignore and .gitattributes, how does git behave and prioritize between the two? Does it ignore pdf files or stores them as LFS?

crashmstr
  • 28,043
  • 9
  • 61
  • 79
shwz
  • 426
  • 1
  • 6
  • 22
  • 1
    Please read the text of tags. `lfs` is not for git large file storage. – crashmstr Nov 10 '17 at 12:49
  • 2
    I do not find this question unclear at all; it simply asks whether files ignored due to `.gitignore` will still be considered by git LFS (as per the `.gitattributes` file). TL;DR the answer is no, but I don't think this question should be closed! – Jonathan H Jan 09 '19 at 14:58

2 Answers2

18

.gitignore tells git that by default it shouldn't pay attention to untracked files at a given path.

.gitattributes tells git to modify how it performs certain operations (if/when it performs said operation) on files at a given path. For git to try to perform those operations usually you at least have to be trying to start tracking the file - and certainly that's the case with the attributes LFS uses.

In both cases, "at a given path" can also mean "matching a given pattern". So there is no conflict or prioritization; we just have to pay attention to what each of these means. If you put *.pdf in .gitignore, and also use .gitattributes to set up *.pdf with the attributes for LFS tracking, then:

  • By default, an untracked PDF file will be ignored by git.

  • To add a new PDF file to the index, you would override the ignore rule with git add -f

  • Once a PDF file exists at a specific path, that path is no longer governed by the ignore rule

  • Any PDF file you do add will be managed by LFS per the .gitattributes

  • Any PDF file already in the repo (which would be unaffected by the ignore rule) should be managed by LFS, though if it was committed before the .gitattributes entry it may not be.

So in this setup, LFS is acting as a safety net to keep PDF files from blowing up your repo database even if someone overrides the ignore rule. Perhaps it means "there are one or two PDF files we really do track; but other PDF files could appear in the work tree, and we generally don't want them."

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
3

.gitignore ignores untracked files — those that haven't been added with git add; .gitattributes are for tracked files. That is, one PDF file could be processed with .gitattributes and two other could be ignored (just an example).

phd
  • 82,685
  • 13
  • 120
  • 165
  • 1
    The `filter` attributes control how files move into the index - including when you first try to add them. So it's slightly misleading to say that attributes are for tracked files. It's more accurate to say that attributes affect how git processes files at a given path, if it does process them; and if a file is ignored and untracked, then by default git doesn't try to process it in the first place. – Mark Adelsberger Nov 10 '17 at 14:17
  • 1
    @MarkAdelsberger: I dunno, I see how one could say that, but if `git add` adds a file (during which it's obeying input-side aka "clean" filters), the file *is* tracked at exactly the same time that the filters are running. I guess it's a matter of whether you see "add cleaned version to index" as "clean first, then add" or "add while cleaning". :-) – torek Nov 10 '17 at 16:10
  • @torek - well, that's true... which is why I only say I think it's *slightly* misleading :) – Mark Adelsberger Nov 10 '17 at 22:25