git on Gitea ignores the repo's .gitattributes and uses its own

[HarvsG]

• Gitea version (or commit ref): 1.9
• Git version: 2.17.1
• Operating system: Ubuntu 18.04
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

Not really sure if this is a bug or a feature. But if a repo has a .gitattributes file the git user running on gitea will ignore it when running functions such as git diff.

E.g lets say on the Gitea instance we have:
git config --global --edit

To the end of the file we add:

[diff "pandoc"]
     textconv=pandoc --to=markdown
     prompt = false
[alias]
     wdiff = diff --word-diff=color --unified=1

And the repo contains a .gitattributes with contents
*.docx diff=pandoc
Ensuring pandoc is installed we get:

However if we set the .gitattributes globally on the Gitea instance we can run git config --global core.attributesfile <path to some global .gitattributes file> and point it at a file containing *.docx diff=pandoc
We get the desired result

.gitattributes is used for customising more than just how diffs are rendered. So I imagine this bug could have further implications.

[guillep2k]

git config has only local scope (your computer), even if you use the --global flag. When you push to a remote (whether it runs on Gitea or not), configuration is not transferred. The --global flag means "for all projects in this computer", not "for all copies of this repository".

[HarvsG]

@guillep2k I am aware of this I will clarify my post to make this clearer

[zeripath]

.gitattributes is only interrogated by non bare repositories.

We use (temporary) bare repositories for almost all of our work - merge is the only place left that does (partial) checkouts but thank you because I now need to check I can't get a merge containing an appropriately malicious .gitattributes to do anything horrible. Edit: thankfully it can't.

In bare repositories if want adjust these options you have to use the config file directly (.git/config) - however I suspect that our extensive use of temporary bare repositories might even prevent that being useful. Edit: I've managed to get myself confused here between gitconfig and gitattributes let me rewrite this...

In bare repositories if you want to adjust the gitattributes file you need to edit the .git/info/attributes file because when you're working in a bare repository you don't usually have a reference index, meaning that the contents of .gitattributes cannot be interrogated. e.g. In git diff branchA branchB - which branches .gitattributes should be used? BranchA, BranchB or even master? The reality is that when you have a working directory - then it just uses the .gitattributes in staged in the index. An argument could be made that you should any one of these branches attributes. In cases of the bare repository git and libgit2 use none of these and just rely on the .git/info/attributes.

Now in our case because we use cleaned temporary repositories I'm fairly certain that when we make these clones the .git/info/attributes aren't cloned (nor for that matter the .git/config) so even if you change the .git/info/attributes files in the gitea-repositories directories that's unlikely to provide the answer.

The only ways to change this are:

• Use global config and attributes as you have already discovered
• Change our code to copy the .git/config and .git/info/attributes when making our temporary clones
• Decide some way of using a .gitattributes from branchA or branchB when creating diffs

I'm not certain how much it worth making these sorts of changes if the global config works.

Looking again at the security considerations of this, I don't think any of these techniques would open Gitea up to security holes in general - however, you should be aware that diff commands need to tolerate arbitrary inputs safely.

---

Edit: I managed to confuse gitattributes and gitconfig here a bit so I've rewritten this comment.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. You can re-open it if needed.