Why is my .gitattributes file not working on my Mac?

Question

Trying to implement a terminal based workflow, becoming more fluent in Github and Git and I wanted to upload all my local AppleScript apps and scripts to a repository through the terminal. Upon initial test upload, anything with a .scpt extension is treated as binary and will not render as raw but only allows a download to view raw.

So researching for a way to turn binary to text so I can utilize version control I found "Should the .gitattributes file be in the commit?" and:

I clone my repo locally in the terminal using:

git clone https://github.com/user/foobar.git

after cd into that directory I do: touch .gitattributes

verified file is there with: ls -a

opened the file with: open .gitattributes

added the following to .gitattributes:

## Explicitly declare text files you want to always be normalized and converted to native line endings on checkout.
*.scpt text

## Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

back in the terminal I do git commit -am "adding gitattributes"

run git push

In the browser I verify that the file .gitattributes is present and it is and I can see it as text.

I add foobar.scpt to my local directory. In the terminal I run ls -a to verify foobar is present and it is. Run git add foobar.scpt then use git commit -am "adding test script" and git push.

When I open the file foobar.scpt in the browser it still indicates I can only download to view raw. Researching further I found:

• How to setup git attributes
• Should the .gitattributes file be in the commit?
• How can I commit files with git?
• How to create file execute mode permissions in Git on Windows?
• How can I Remove .DS_Store files from a Git repository?

I've tried the above with:

• adding the .gitattributes to my local as .git/info/.gitattributes
• adding the .gitattributes to my local as .git/info/gitattributes to replicate how the exclude file looks.

I've changed the gitattributes file parameters to:

• *.scpt text
• *.scpt diff

After trying all the above I'm still unable to get some files as text instead of binary. What is the proper way to create a gitattributes file locally and push it to the master so that Mac files will be rendered as text and not binary?

---

Edit:

A comment suggested How would you put an AppleScript script under version control? so I git rm foobar.scpt, git commit -am "removed test" and git push.

After removing foobar locally I updated ..gitattributes to:

## Explicitly declare text files you want to always be normalized and converted to native line endings on checkout.
*.scpt diff=scpt

## Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

added to my config file (locally under .git/config):

[diff "scpt"]
  textconv = osadecompile
  binary=true

I've created a new script file named test.scpt and uploaded to through the browser and terminal and still get raw. What am I doing wrong?

Answer 1

I'm not entirely sure from your description whether or not the .scpt files are "partially" or "fully" binary in nature.

• If they are "fully" binary, ala dat,exe or bin formats, then use Git LFS to treat them as such.

  git lfs install         # Installs the Git LFS hooks into you ./.git/ folder
  git lfs track "*.scpt"  # Registers the *.scpt file extention as a binary format
  

  Note: The double quotes are required to apply to all *.scpt files not just those in the project root

  This will track changes to the files using the usual Git work flow, so you can roll back to some prior state. As I understand it Git LFS stores the entire file as is and doesn't track changes in the way that git does, think multiple copies/clones of each file. Big files quickly lead to large repositories and one has to periodically clear out older files, loosing some of the history.

• If they are "partially" binary, ala pdf or docx, then one might configure "readers" for them using .gitattributes. Martin Fenner's article covers this quite nicely (I won't link the plagiarized copy floating about). Essentially he uses .gitattributes to identify a different diff tool and editor for the *.scrpt files and .gitconfig to specify these tools.

  • PATH/TO/Repository/.gitattributes

    *.docx diff=scptdiff
    

  • SOME/PATH/.gitconfig (I can't recall where .gitconfig lives)

    [diff "scptdiff"]
    textconv=SCPT2TEXT ...
    prompt = false
    [alias]
    scptdiff =SCPTDIFF ...
    

  Note: SCPT2TEXT represents the *.scpt reader/converter and SCPTDIFF the *.scpt diff tool and ... their arguments excluding the file name

  Here git version control upon the file. It will track changes for you but might lead to issues during merging; I haven't used this in a while but I recall it working well enough.

• Using .gitattributes one may also mark a file as binary in which case git will simply copy the file around but not track any changes. Two people editing the file will end up overwriting one anothers work. This is meant more for data files that change infrequently.

Personally I suspect your issue has more to do with line endings. You appear to be changing from CRLF to LF, or vice versa. This is probably breaking the scpt format the when you push to the central repository. During the push the line endings get converted and the file "mangled", then you download the "mangled" file from the server only to find it is truly mangled; this is probably why they are not "viewable" in the web interface. If you reverted the line endings in the mangled file you would get the original "fixed" file back again.

My rule is switch line endings between Windows <-> Linux and leave them for Linux <-> Linux; treat the server as a Linux box; treat Mac OS as Linux. Set this up within the system/local/user .gitconfig. Only if really necessary then enable, text/crlf, or disable, text/crlf, line end switching altogether in .gitattributes e.g. binaries under git that only one person might edit, or that would be corrupted otherwise.

Colleagues may also be breaking files by converting when they pull but not when they push or vice versa. Again en/disable this within .gitattributes.

note : This doesn't quite answer the question; please ask for further information as necessary. Also I don't work upon Mac OS so I might be out on a few things

Answer 2

Do you have any evidence that you can normally open .scpt files as text on your browser from this specific web server/application?

.gitattributes only control how git handles certains aspects of file handling that may vary between systems. For instance, text means that git may automatically convert to/from local OS text format when it differs from the committed version (see for instance core.eol in the git-config manual). If you have to use this type of conversion you should also define a standard line ending format for all your files (it can be anything), and each client can decide to retain the native format or convert to local format based on their client config.

That has nothing to do with browser being able to open the file as text. This is controlled by the web server or application servicing the HTTP request and the MIME type it will send to your browser using the Content-Type: HTTP header. Yours is probably not recognizing the .scpt file extension and sending these files as a generic application/binary type.

The configuration of MIME types is very OS-specific and application-specific. On Linux the default system MIME types are defined in /etc/mime.types but it's also up to the web server to read this file or provide its own, and many also allow additional types to be defined in the config.

On top of that, for requests serviced by an application it's the application that defines the MIME type to use, which likewise can use the system config or its own. For example when browsing a git repo, the web server can't access the file directly on disk so a web app is extracting the file from a "git database" (usually a bare git repository) and will determine what MIME type to return for that specific file, most likely based on the file extension.

It could be argued in this case git knows it's text, yet that doesn't mean text/plain should be used as many plaintext format have very specific MIME times. Changing all of them to text/plain would break almost every other text-based file formats; for example html is text, but it would be quite problemattic if your web browser started showing html pages as plain text.