title: Merging branch that adds new Git LFS type
body: <p>I have an existing Git repository that I've already enabled Git LFS on. I already have this repository using LFS for <code>*.foo</code> files, and this is evident in the <code>.gitattributes</code> file.</p>
  
  <p>I have a branch <code>add-bar</code> on which I decide I want to use Git LFS for <code>*.bar</code> files as well. (I haven't added any <code>*.bar</code> files to repository yet; my question is not about migrating existing content.) In my <code>add-bar</code> branch I will do this:</p>
  
  <pre><code>git lfs track "*.bar"
  </code></pre>
  
  <p>I believe this will update my <code>.gitattributes</code> file again. Then I will add my <code>.bar</code> file.</p>
  
  <pre><code>git add example.bar
  git commit -m "Added my first bar."
  git push -u origin add-bar
  </code></pre>
  
  <p>I'm unsure of exactly how merging back into <code>master</code> will work.</p>
  
  <pre><code>git checkout master
  git merge add-bar
  git push
  </code></pre>
  
  <p>The <code>add-bar</code> branch has its <code>.gitattributes</code> updated to reflect LFS handling <code>*.bar</code> files, but the <code>.gitattributes</code> in <code>master</code> does not. Will the merge happen correctly? Will LFS correctly be used for <code>*.bar</code> files, even though <code>.gitattributes</code> in <code>master</code> doesn't know about them before the merge? Will <code>git push</code> happen correctly even though the <code>*.bar</code> files were merged before they were recognized as controlled by LFS?</p>
  
  <p>I'm probably not even asking exactly the right questions, or not asking them in the right way. This will probably become obvious the more I work with Git LFS—maybe I just need to review its mechanism again. But hopefully this question and the answers will be helpful to others as well.</p>
  
  <p>To summarize, I'm just unsure of how merging works with Git LFS if the different branches have different <code>.gitattributes</code> settings, and at what point LFS takes over.</p>