I have changed line of a sql file file. But the diff only shows the diff colour without any change code.
the line is: #enabled=0, before the change we had 1 instead of 0.
without the gitattribute
*.sql text diff
I get the error message that file suppressed by a .gitattributes entry or the file's encoding is unsupported.
[this is the link of the image of my git diff] (https://i.stack.imgur.com/bgMvv.png)
You need to check your git status (assuming the #enabled=0 was done on your workstation)
Check if:
the file is indeed Test/Scripts/ScriptsIgnoredOnImport.sql
there is any local commit which would not have been pushed yet.
The file on GitHub can also tell you more, by typing b (which triggers the file "blame" view on GitHub).
As shown here, you can then "View blame prior to this change" and see if your #enabled= was visible then.
As noted by torek, you could have a difference in encoding as well.
As I mentioned in "How do I determine file encoding?", you can (even in a simple CMD on Windows), check the encoding of your current file with:
git show :your/file.sql | file -
# compare it with the previous version
git show #~your/file.sql | file -
Related
Is there any way to remove the username and computer name from Git Bash for Window 10?
I already checked this : https://github.com/Maximus5/ConEmu/issues/199
But didn't understand how to do that.
Follow the steps below:
Go to C:\Program Files\Git\etc\profile.d\ folder
Find and open the git-prompt.sh file in your favorite text editor
Go to line number 15
Replace the whole line with PS1="$PS1"''
That's it. Start/Restart Git Bash and you should see the username and computer name is gone.
NOTE: You can also hide the annoying MINGW64 text by commenting out the line number 16 and 17 of the same file. To comment out those lines just add a # to the beginning of the line. That's it. Now start/restart Git Bash and it should go away.
Better way!!
Follow the steps as mentioned by #Saabbir, with one big change:
# 👇 comment out the wrapping if-else block
if test -f ~/.config/git/git-prompt.sh
then
. ~/.config/git/git-prompt.sh
else
# 👇 leave the content uncommented
...
fi
Save the file, git-prompt.sh using Save As (in your editor) in this path C:\Users\{current_windows_user}\.config\git
Explanation: You can see on line number 8 that it checks for the same file on ~/.config/git. So it's better to update the config file rather than the actual settings file.
Currently I have the following cron.file formula
date > system_cron:
cron.file:
- name: salt://crons/cron_jobs
- source_hash: "md5sum=895dcbbddd27bfa77056ef8c8340549a"
- user: security
But this updates the crontab each time the highstate is run event though the cron_jobs file has not changed and hence the state is the same.
Is there a way to stop creating temp crontab file each time highstate is run when using cron.file
I found that this happens when you have blank lines at the end of the file, or if you have dos line endings instead of unix line endings. Once this has been changed, the file will only be updated when it has changed.
Please note: as you have placed the file in "salt://", you don't need source_hash. This is only required for remote (i.e. http) files.
I am trying to zip a file using shell script command. I am using following command:
zip ./test/step1.zip $FILES
where $FILES contain all the input files. But I am getting a warning as follows
zip warning: name not matched: myfile.dat
and one more thing I observed that the file which is at last in the list of files in a folder has the above warning and that file is not getting zipped.
Can anyone explain me why this is happening? I am new to shell script world.
zip warning: name not matched: myfile.dat
This means the file myfile.dat does not exist.
You will get the same error if the file is a symlink pointing to a non-existent file.
As you say, whatever is the last file at the of $FILES, it will not be added to the zip along with the warning. So I think something's wrong with the way you create $FILES. Chances are there is a newline, carriage return, space, tab, or other invisible character at the end of the last filename, resulting in something that doesn't exist. Try this for example:
for f in $FILES; do echo :$f:; done
I bet the last line will be incorrect, for example:
:myfile.dat :
...or something like that instead of :myfile.dat: with no characters before the last :
UPDATE
If you say the script started working after running dos2unix on it, that confirms what everybody suspected already, that somehow there was a carriage-return at the end of your $FILES list.
od -c shows the \r carriage-return. Try echo $FILES | od -c
Another possible cause that can generate a zip warning: name not matched: error is having any of zip's environment variables set incorrectly.
From the man page:
ENVIRONMENT
The following environment variables are read and used by zip as described.
ZIPOPT
contains default options that will be used when running zip. The contents of this environment variable will get added to the command line just after the zip command.
ZIP
[Not on RISC OS and VMS] see ZIPOPT
Zip$Options
[RISC OS] see ZIPOPT
Zip$Exts
[RISC OS] contains extensions separated by a : that will cause native filenames with one of the specified extensions to be added to the zip file with basename and extension swapped.
ZIP_OPTS
[VMS] see ZIPOPT
In my case, I was using zip in a script and had the binary location in an environment variable ZIP so that we could change to a different zip binary easily without making tonnes of changes in the script.
Example:
ZIP=/usr/bin/zip
...
${ZIP} -r folder.zip folder
This is then processed as:
/usr/bin/zip /usr/bin/zip -r folder.zip folder
And generates the errors:
zip warning: name not matched: folder.zip
zip I/O error: Operation not permitted
zip error: Could not create output file (/usr/bin/zip.zip)
The first because it's now trying to add folder.zip to the archive instead of using it as the archive. The second and third because it's trying to use the file /usr/bin/zip.zip as the archive which is (fortunately) not writable by a normal user.
Note: This is a really old question, but I didn't find this answer anywhere, so I'm posting it to help future searchers (my future self included).
eebbesen hit the nail in his comment for my case (but i cannot vote for comment).
Another possible reason missed in the other comments is file exceeding the file size limit (4GB).
I converted my script for unix environment using dos2unix command and executed my script as ./myscript.sh instead bash myscript.sh.
I just discovered another potential cause for this. If the permissions of the directory/subdirectory don't allow the zip to find the file, it will report this error. Actually, if you run a chmod -R 444 on the directory, and then try to zip it, you will reproduce this error, and also have a "stored 0%" report, like this:
zip warning: name not matched: borrar/enviar
adding: borrar/ (stored 0%)
Hence, try changing the permissions of the file. If you are trying to send them through email, and those email filters (like Gmail's) invent silly filters of not sending executables, don't forget that making permissions very strict when making zip compression can be the cause of the error you are reporting, of "name not matched".
spaces are not allowed:
it would fail if there are more than one files(s) in $FILES unless you put them in loop
I also encountered this issue. In my case, the line separate is CRLF in my zip shell script which causes the problem. Using LF fixed it.
I've set up my ~/.hgrc as per https://www.mercurial-scm.org/wiki/MergingWithVim to use vimdiff.
[ui]
merge = vimdiff
[merge-tools]
vimdiff.executable = vim
vimdiff.args = -d $base $local $output $other +close +close
However, when I try to run the actual merge, it just fails out not very helpfully with the following:
bash-3.2$ hg --debug merge
searching for copies back to rev 7
resolving manifests
overwrite None partial False
ancestor 88aaf3a2e10f local 311bb03b96cd+ remote 29bec6ac5dd3
junk: versions differ -> m
preserving junk for resolve of junk
updating: junk 1/1 files (100.00%)
picked tool 'vimdiff' for junk (binary False symlink False)
abort: Operation not supported: /Accounts/rainest/mtest/junk.orig
Any idea why it's doing this?
I've figured it out.
It turns out there's a very specific bug in Python2.6's shutil library that occurs if you're working with NFS mounts on a BSD-like system. More information, and the fix, can be found at http://bugs.python.org/issue7512.
Depending on how you installed it Mercurial usually comes with vimdiff pre-configured for merging. On my machine that's in /etc/mercurial/hgrc.d/mergetools.rc but I imagine it's different in your OSX box.
You might want to check to see if it doesn't already use vimdiff for merging if you remove all of that from your .hgrc.
You can use the command hg showconfig --debug to see all the per-user, per-repo, and system-wide configuration items that are in effect. If you see vimdiff in there after the lines you've added are removed then you might be good to go.
I'm having trouble applying a patch to my source tree, and it's not the usual -p stripping problem. patch is able to find the file to patch.
Specifically, my question is how to read / interpret the .rej files patch creates when it fails on a few hunks. Most discussions of patch/diff I have seen don't include this.
A simple example:
$ echo -e "line 1\nline 2\nline 3" > a
$ sed -e 's/2/b/' <a >b
$ sed -e 's/2/c/' <a >c
$ diff a b > ab.diff
$ patch c < ab.diff
$ cat c.rej
***************
*** 2
- line 2
--- 2 -----
+ line b
As you can see: The old file contains line 2 and the new file should contain line b. However, it actually contains line c (that's not visible in the reject file).
In fact, the easiest way to resolve such problems is to take the diff fragment from the .diff/.patch file, insert it at the appropriate place in the file to be patched and then compare the code by hand to figure out, what lines actually cause the conflict.
Or - alternatively: Get the original file (unmodified), patch it and run a three way merge on the file.
Wiggle is a great tool for applying .rej files when patch does not succeed.
I'm not an expert on dealing with patch files, but I'd like to add some clarity on how to read them based on my understanding of the information they contain.
Your .rej files will tell you:
the difference between the original and the .rej file;
where the problem code starts in the original file, how many lines it goes on
for in that file;
and where the code starts in the new file, and how many lines it goes on for in that file.
So given this message, noted in the beginning of my .rej file:
diff a/www/js/app.js b/www/js/app.js (rejected hunks)
## -4,12 +4,24 ##
I see that for my problem file (www/js/app), the difference between the original (noted as a/www/js/app.js on the first line) and the .rej file (noted as b/www/js/) starts on line 4 of the original and goes on for 12 lines (the part before the comma in ## -4,12, +4,24 ## on line two), and starts on line 4 of the new version of the file and goes on for 24 lines (the part after the comma in ## -4,12, +4,24 ##.
For further information, see the excellent overview of patch files (containing the information I note above, as well as details on lines added and/or between file versions) at http://blog.humphd.org/vocamus-906/.
Any corrections or clarifications welcome of course.