I want to take advantage of gitlab image diff during merge request. However, instead of the image being rendered or the diff, this is what I'm getting:
A message saying: This diff was suppressed by a .gitattributes entry.
This is the .gitattributes file that we have setup, I don't understand how this is avoiding the image to show properly:
* text=auto
*.* text eol=lf
/.idea/* text eol=crlf
*.png binary
*.jpg binary
*.ico binary
*.pdf binary
If I remove the entry for PNG, then it is treated as text and the checked out images are not valid. What is the way to flag png as normal image files? What is the default? This seems to work if there is no .gitattributes file at all, so what is the proper one?
Thanks in advance
You could add the diff attribute to the .gitattributes file.
*.png binary diff
The behavior is slightly different. The diff is not collapsed by default. But it's ok I think.
Related
I found a command on another thread that works perfectly for converting a specific color to a transparent color which I've tested on one directory. However I have many images in different direcorties that I need to do this to. The file structure cannot change, ideally the command will simply replace the current image with the old one. As the command runs now it creates a new file in the /batch directory.
for file in *.png ; do convert "${file}" -transparent '#bbb7b9' "batch/${file}" ; done
So the two modifications to this command would be:
1) The command executes recursively
2) The original image is replaced with the new one (with the same filename)
I've researched and found that using the find command may be what I need but I'm confused about how to translate this over from the for command... It looks like some variation of -exec may be what I need but I haven't found anything that works.
Thoughts/Ideas?
In ImageMagick, you can use the mogrify command to process a whole folder of images (no automatic recursing to subdirectories).
cd to your image directory
mogrify -format png -transparent '#bbb7b9' *.png
However, I would suggest either creating a new directory to hold your output images or creating a backup copy of your input directory, so that you do not make a mistake and write over your images with bad copies.
See http://www.imagemagick.org/Usage/basics/#mogrify
Im using a windows system to push my changes to a git linux server, where users commit with macOS, could this be the problem of invalid diff changes? changes which are not changes are displayed as deleted and later on re-added as new somehow. im using sublime and also tryed netbeans with the same behaviour...
Windows and *nix based operating system use different line ending character in files. In your case you are adding the Windows Carriage return character in your file and on MacOSX they are removed.
On your Sublime you can change the line ending character on save to match the MacOSX's line ending . See is there a way to convert files line ending on saving. This way you will not see these changes.
You could also instruct git to automatically do the conversion with the core.autocrlf config. See GitHub dealing with line endings
GitHub suggests that you should make sure to only use \n as a newline character in git-handled repos. There's an option to auto-convert:
$ git config --global core.autocrlf true
Of course, this is said to convert crlf to lf, while you want to convert cr to lf. I hope this still works …
And then convert your files:
# Remove everything from the index
$ git rm --cached -r .
# Re-add all the deleted files to the index
# You should get lots of messages like: "warning: CRLF will be replaced by LF in <file>."
$ git diff --cached --name-only -z | xargs -0 git add
# Commit
$ git commit -m "Fix CRLF"
As Per Git Config Manual
core.autocrlf
Setting this variable to "true" is almost the same as setting the text
attribute to "auto" on all files except that text files are not
guaranteed to be normalized: files that contain CRLF in the repository
will not be touched. Use this setting if you want to have CRLF line
endings in your working directory even though the repository does not
have normalized line endings. This variable can be set to input, in
which case no output conversion is performed.
The remote repo has mixed cr/lf lineendings, thought it was unix, now i just set the original lineending if it happens again.
Does veracrypt do any sort of file caching in memory that might be preventing changes to my git config files to be recognized?
Long version: I have a repo on a veracrypt partition shared with Windows. While trying to enforce EOL's in my repo, I am seeing files more or less arbitrarily setting EOL's. When making a trivial change to my .gitattributes file, I'll merge this change onto a branch, and suddenly my new branch is filled with files with EOL-only changes.
I'm working on linux using mostly SmartGit or the cmd-line (git v 1.8.3.1). I've tried removed autocrlf and safecrlf or setting to false in both my global and repo config files in case they were confusing things. I've tried deleting my .gitattributes file, or setting
* binary
To prevent any conversion at all.
I have reset dozens of times, and deleted my local repo and re-cloned. But I cannot get rid of these modified files
git rm --cached -r .
git reset --hard
Below is my .gitattributes
# Auto detect text files and perform LF normalization
* text=auto
# Specify LF file endings for coding files
*.txt text eol=lf
*.c text eol=lf
*.cpp text eol=lf
*.h text eol=lf
*.py text eol=lf
*.kl text eol=lf
*.json text eol=lf
# Specify windows-only CRLF endings
*.bat text eol=crlf
*.vcproj text eol=crlf
*.sln text eol=crlf
# Specify binary files - do not modify these files, dammit!
*.so binary
*.dll binary
*.lib binary
*.pdb binary
*.exp binary
*.exe binary
My major problem is that some (not all) .so symlinks are showing up modified in one particular branch - looking for all the world like they've been converted. This consistently occurs in my latest branch, but not earlier branch. In the current spate of madness, my last merge added the *.cpp tag, which promptly converted some (not all) of my *.py files to windows line endings.
Has anyone experienced this kind of unreliability? Is the .gitattributes file supported in this version of git? Is veracrypt or the NTFS partition somehow confusing things on me?
I've been working on what should be a trivial task for a week now, and simply cannot fathom how git is deciding on its EOL strategy.
I still don't know precisely what is going wrong, but I recreated the repo, and as long as I never touch (use it read-only) it in windows it seems ok.
I tried to pull some changes while I had some files opened in vim, and while committing and merging and the sort, ended up coming up with:
alex#adebian:~/cs4290/p3$ hg status
R test
! project3_framework/protocols/.MI_protocol.cpp.swp
! project3_framework/protocols/.MSI_protocol.cpp.swp
I added a .hgignore file in my project with the following:
syntax: glob
*.cpp.swp
I've since closed my vim session (removing the files) yet the files keep showing up. How do I get mercurail to ignore the .swp files?
! sign means that mercurial cannot find the file that has been already added to the repository. So you need to forget or remove those files at first. After that - they will not appear anymore in the status since you have ignored them.
I agree with zerkms... forget or remove those files to get rid of the !. Also, as you've probably noticed, simply creating a .hgignore file with some content does not go through the repository and remove matching files. If you've added foo.c to your project and then you create the following .hgignore:
syntax: glob
*.c
foo.c will still be a part of the project - you would need to remove it explicitly.
You can use
set directory=c:\\workfiles\\
in your .vimrc to write swap files in a "special" folder
I'm creating a zip file by relatively specifying file locations. Here is an example of the command I'm running:
zip priv/purchases/test.zip priv/audio/5001.mp3 priv/audio/5002.mp3
When the file compresses it maintains the relative paths of the files. Thus I get a file hierarchy of:
/priv
/audio
/5001.mp3
/5002.mp3
I've read the man page and I guess I should be using the -j flag. Instead I'd like the files to be extracted at the root of the uncompressed file.
-j seems to work but it ALSO includes the file structure. Why?
Well don't I feel silly. Apparetly if you don't remove the previous directory it seems to append the files. Shoot! Haha.