So, I somehow didn't realize what this was when I was looking at it, but this is the first line in our .gitattributes * text eol=lf It all makes sense now. And, yea, we're using git to retain dependency relationships and bring those files under version control so we can audit changes and go through the full peer review process, etc On Fri, Aug 20, 2021 at 2:51 PM Randall S. Becker <rsbecker@xxxxxxxxxxxxx> wrote: > > On August 20, 2021 3:15 PM, brian m. carlson wrote: > >On 2021-08-20 at 18:47:02, Jonathon Anderson wrote: > >> On Fri, Aug 20, 2021 at 1:00 PM Jeff King <peff@xxxxxxxx> wrote: > >> > > >> > On Thu, Aug 19, 2021 at 01:21:03PM -0500, Jonathon Anderson wrote: > >> > > >> > > I had not. I tested that and it worked. I assumed that git would > >> > > automatically treat dll files as binary. Thanks for the help! > >> > > >> > Git doesn't know about any file extensions by default. Its default > >> > "is it binary" test looks for NUL bytes in the first 8k or so of the file. > >> > I'd expect your DLL would probably have such a NUL byte. > >> > > >> > Is it possible you have other .gitattributes set which are confusing > >> > things? > >> > > >> > You might try: > >> > > >> > git check-attr --all <path> > >> > > >> > or: > >> > > >> > git ls-files --stdin | git check-attr --stdin --all > >> > > >> > -Peff > >> > >> When I remove '*.dll binary" from .gitattributes, I get this: > >> > >> $ git check-attr --all ./PSWindowsUpdate.dll > >> ./PSWindowsUpdate.dll: text: set > >> ./PSWindowsUpdate.dll: eol: lf > > > >Yes, this is definitely not correct. The flag "text" being set tells Git to do line-ending conversion and "eol=lf" says to convert line endings > >into LF. > > > >You should look for things in your .gitattributes file that say something like "* text", which you probably don't want. You could use > >"* text=auto", which should be fine for most cases, though. It's also possible those aren't in a .gitattributes file in your repository but one > >elsewhere on your system. You can check gitattributes(5) for the locations of other files that can affect it. > > > >As a note, it is best practice not to check binary dependencies or build artifacts into the repo. Those are best stored elsewhere, such as an > >artifact server. > > OT: Unless you are using git as an artifact repository to retain the dependency relationship between objects and the source commits that built them for PCI and SWIFT compliance. git is exceptional when it comes to evidence-of-origin forensics of specific installation artifacts when release structures are more complex than "deploy everything" use cases. But that may be a discussion we can have elsewhere. > > Just my $20.00. > -Randall >
