Add .textClipping to exclusions

[nmdange2]

I ran into the issue referenced in #3523 and I'm not sure how to fix it. I want to add the .textClipping exclusion without breaking the other rule so this pull request should not be accepted until the other one is first.

Reasons for making this change:

Files with the .textClipping extension should be ignored.

Links to documentation supporting these rule changes:

Per https://en.wikipedia.org/wiki/TextClipping this file is created when text is dragged and dropped to a folder. The file created can't be shared between computers.

[i-to-r]

Did you edit the macOS.gitignore file through a browser (https://github.com/github/gitignore/edit/master/Global/macOS.gitignore)?

And if so, did you see the message:

We’ve detected the file has mixed line endings. When you commit changes we will normalize them to Windows-style (CRLF).

?

[i-to-r]

@nmdange2, unfortunately the fix #3523 won't help you directly. GitHub online editor (browser, CodeMirror editor) still corrupts the Icon[␍] rule (i-to-r/gitignore@123480c), but the fix will preserve the line endings ␊ of the rest of rules (i.e. the message "We’ve detected the file has mixed line endings. […]" will not appear).

After the fix #3523 is ​​merged, you should make a commit using, for example, GitHub Desktop and the default TextEdit.app to edit the file (among web browser based editors: latest Atom works fine too, but old Brackets 1.8 don't — but in GitHub Desktop, you can still select which changed lines to include in the commit ^{partial commit} ).

[nmdange2]

@i-to-r Thanks I'll try redoing the commit in something other than a web browser

[tempelmann]

Please do not exclude .textClipping files by default.

Reason: Before macOS 10.12, textClippings were only stored in the rsrc fork, which isn't handled by git, and therefore would lead to a complete loss of information.
However, since 10.12, newly created .textClippings are also stored in the data fork, in binary plist format, containing the same keys (types) and values of the rsrc entries of ID 256.
And macOS does, when opening (double clicking) these files, show the correct contents. Only quicklook does not work with the data fork but still (even in macOS 12.1) look only at the rsrc fork's data.
Which means, that if you restore a .textClipping file from git, the data fork will still be there, containing all the information (allowing to view the clipping by double clicking it), but which would also allow the restoring of the rsrc fork data to make quicklook work again.
In fact, I'm currently working on a little tool to do exactly that:

1. If a textclipping has data only in its rsrc fork (data fork being empty), it'll copy the clip rsrc content into the data fork. This would be performed on old clips created pre-10.12, so that git will then preserve the contents in the data fork.
   2.If a textclipping has no rsrc fork but a data fork, it restore the rsrc fork accordingly. This would be done after restoring from git, so that quicklook works again.

[tempelmann]

OTOH, it would be much nicer if rsrc forks could also be handled by git, by using the "..namedfork/rsrc" path method. That sub-path allows both reading and writing rsrc forks as regular files.
(And no, rsrc forks are not always meta data, but may contain primary data, as in the case of Finder Alias, .textClipping, .webloc, etc. – it depends on the context and file type)

[github-actions]

This PR is stale because there have been no updates in 90 days. It will close after 180 days of inactivity. Leave a comment if you want to keep it open 😄

[tempelmann]

There's some "new" behavior:

Recent macOS versions do actually use the data fork with .textClipping files. In fact, in my tests, the same information is stored both in the data and the resource fork. I even made a program (not made public yet) that can recreate the missing side.

So, with this knowledge, there's no need to exclude .textClipping files any more, because they do now store content in the git repo, as long as the file have been created by a recent macOS version.

There remains one caveat, though: When restoring such a file from the repo onto a macOS system, some macOS features do not work, e.g. Quicklook can't show the textClipping's contents if it's stored only in the data fork while the data in the rsrc fork is missing. I've reported this as a bug to Apple in 2022 (FB9920034), and nothing has changed, of course. Still, someone could write code to restore the rsrc fork when restoring such a file, and then it would work fine.

If someone likes to tackle this, I'm happy to provide the code for the conversion from the data to the rsrc fork.