`vim.pot` is included in the repository after
```gitcommit
commit 59bd74ed4c
Author: Christian Brabandt <cb@256bit.org>
Date: Sun Jul 13 08:26:57 2025 +0200
translation: include vim.pot in the repository
```
And it adds quite a lot of noise to the diffs since then. See the
reasoning in a comment in `.gitattributes`.
I'm not 100% sure that marking it as binary would have no negative side
effects. But I was not able to find a better option in `git help
attributes`.
Solution suggested in
```gitcommit
commit 5d552d652b
Author: Christian Brabandt <cb@256bit.org>
Date: Tue Jul 15 20:42:48 2025 +0200
translation: ignore vim.pot creation date, regenerate it, rm allfiles
Signed-off-by: Christian Brabandt <cb@256bit.org>
```
does not seem to be solving the problem. It only hides the
`POT-Creation` line from the `vim.pot` diff. Maybe a more elaborate
filter could be used - one that replaces lines numbers in `vim.pot` with
`xxxx`, thus removing the most annoying and useless part of the diff.
One downside is that it requires everyone to install such a filter
locally - it can not be part of the repo config, as far as I understand.
closes: #17775
Signed-off-by: Illia Bobyr <illia.bobyr@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Update the textconv filter to filter out changes in the comments
pointing to the location of the message.
Also remove the comments in vim.pot that mention the message location.
Since those will be ignored using vims textconv filter, it does not make
sense to keep them, they would get out of sync anyhow.
closes: #17782
Co-authored-by: Illia Bobyr <illia.bobyr@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Regenerate vim.pot because of a wording update in optwin.vim for the
diffanchors feature.
While at it, update the textconv filter to ignore all lines
containing version.c because those change just by incrementing
the Vim patch number *grummel*
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Test42 seen as binary by git diff.
Solution: Add .gitattributes file. Make explicit that 'cpo' does not
contain 'S'. (Daniel Hahler, closes#5072)