ignore global core.attributesFile

[andreineculau]

scenario: you have a global .gitattributes for settings crlf, text/binary, diff etc settings

then this is what you get

$ transcrypt --list-contexts                                                                                                                                                             default (no patterns in .gitattributes)
custom (no patterns in .gitattributes)

instead of

$ transcrypt --list-contexts                                                                                                                                                             default
custom

although the .gitattributes in the repo has the patterns defined

Point is: do we really support transcrypt globally? with custom contexts?
If we do, then we need to check all attributes files, not only the first one.

PS: on a different note, it also doesn't make sense (to me at least) that --add=<pattern> write to anything but a local gitattributes

[jmurty]

The check against non-local .gitattributes was added in #137 and although I don't tend to us config files like .gitattributes from outside the immediate repo directory, some people do. I can imagine for example situations where you want transcrypt to encrypt *.secret files across all your projects, in which case putting this in a global .gitattributes would make sense.

So I think the right fix here would be to check all attributes files, which won't necessarily be easy.

[jmurty]

See a potential alternative solution that finds contexts across all gitattributes files, not just one, in #202

[andreineculau]

I saw the fix in #202 and the code is 👌 but it doesn't update the add_pattern function

And that's also a symptom for why I can't get myself to approve #202 - how will you decide which file to amend with transcrypt --add ?

some people do

That's not a reason in itself to allow something, right?

Here's a scenario: including a global .gitattributes in the picture means that you and I end up with different transcrypt behaviour. I'm certain that your transcrypt Turing machine is better than mine, but this is how I see things go:

• I like to encrypt everything in 🇸🇪 "hemlis" folders, and I do it in many of my personal repos, so I add it to my global .gitattributes
• We start collaborating on a repo
• I start adding files to "hemlis", I stage, commit, push
• You clone/pull my repo, you have the transcrypt password, decrypt and....
• You don't have the files inside "hemlis" decrypted
• 🤬

How does that make sense? It means transcrypt relies on out-of-bound information about which files are encrypted and which are not. All of this becomes even more bananas when you think of multiple contexts. Essentially you have an out-of-bound layer of metadata that says which files are encrypted with which context. For what gain exactly?

Looking at the git history, I see we starting reading more than just the literal .gitattributes in 150660b 9y ago to "solve" #18 as a way to support git archive. At that point we started to support .git/info/attributes

Then in 4892d7f we started reading core.attributesFile to resolve #12 to support vcsh ?! Never heard of it, and I can't think of something more niche than this.

Except for this case, do you know of other "some people do" and their use-case?
I don't know how important you would consider support for vcsh, but if you do, I want to bet that there's other ways to support than going for core.attributesFile. Note that the original issue talks about the GIT_ATTRIBUTES env var, which is same-same-but-different to supporting global attributes via core.attributesFile i.e. env var vs config , but also see how Aaron simply decided to extend the behaviour outside of VCSH in fbc611d .

All of the above tells me that the current behavior might not be by design. At all.

PS: the reasoning might as well be extended to .git/info/attributes - why support it at all? Beyond supporting git archive, I can think of one more reason - it can actually be used for deduplication e.g. turn .git/info/attributes into a symlink to a shared location. We use .git/info/exclude like this to set shared gitignores. To simplify .git/info/attributes is a repo-level setting (making it user level requires intent), while core.attributesFile is a user-level setting. Using core.attributesFile to automate turning an image into "text" (exif) is a very very different thing to marking the file for encryption when pushing upstream.