I was playing around with terminal themes where I probably did something with Vim. And now I am trying to open a file with vim in terminal and it shows messy code:
That's not your code. You appear to have opened the executable generated by your compiler, thus the garbled text. That, or you overwrote the source file during compilation with something like
gcc src.c -o src.c
If the former, then just open the correct file.
If the latter, then your file is gone. Since you tagged macos, I suggest checking Time Machine for a backup. Also, if this file was under source control (eg. git), then you should still be able to retrieve it. For example, if you're using git,
git reset HEAD src.c
git checkout -- src.c
Related
Hi I am trying to update one of my remote repositories. When I use commit in git bash it shows that a SWP file already exists and askes me if I want to (R)ead only the file (E)dit (D)elete. I tried editing the file, but I cannot save the changes and therefore cannot commit my changes. Any idea what is going on.
EDIT:
It's working now thanks to those that helped. In terms of the question I will try to only show the relevant information when asking questions in the future.
When you edit a file, Vim stores your changes in a "swap file" so that you can recover your work if Vim's process is killed before you could save. This can be caused by something as problematic as a system crash or, simply, by closing your terminal window while Vim is running.
If Vim is quitted "normally", it deletes the swap file it created.
If it is not, the swap file is left behind and, the next time you open the same file, Vim will notice the presence of the swap file and offer you the possibility to recover the work that you "lost" the last time Vim quitted "abnormally".
That is the interactive screen you get with the "(R)ead only the file (E)dit (D)elete" prompt.
Now, when you are starting out with stuff like Git, Vim, the command line, etc. it may happen quite often that you find yourself in an uncomfortable situation, not knowing exactly what to do to fix it. This is frankly quite normal at this stage. In those situations, closing the terminal window might seem like a good first step in going back to a more comfortable situation to start again. In some cases, however, doing so might leave a trail of hidden files and broken states that might make it harder than you hoped to get to that comfortable situation.
When you do $ git commit, Git populates a specific temporary file located in your local .git directory:
.git/COMMIT_EDITMSG
with some text describing the commit you are about to make, and opens that file with your designated editor, which is the dreaded Vim by default.
When you start editing the file, Vim creates a swap file. If you insert your commit message, write the file, and quit Vim normally, the swap file is deleted and you won't ever be prompted about it. If you close the terminal window before writing the file, the swap file stays behind and Vim will prompt you about it the next time you try to make a commit.
From there you have quite a few options…
Go into your .git directory and delete the swap file(s) manually. They should be named .git/.COMMIT_EDITMSG.swp (or .swo, .swn, etc. see :help swap-files in Vim). This should give you a clean state for the next time you do $ git commit.
Don't close your terminal window when faced with a problem. Instead, try to analyze what went wrong and look for proper ways to fix it. If you have to close the terminal window, look for stray swap files just in case.
Learn Vim's basics so that you don't have to close the terminal window when you mess up your commits. Try $ vimtutor.
Tell Git to use a text editor you are more familiar with. Search Stack Overflow, I am sure there are dozens of Q/As about that.
Configure Vim to never create swap files. You can do it in Vim's configuration file:
# in $HOME/.vimrc
set noswapfile
This won't tell it to ignore existing swap files, though, so you might want to delete them manually anyway.
Use a graphical Git client instead of the CLI.
I have read so much about the config setting core.autocrlf and what you can set it to. Yet I am having a lot of problem understanding why it doesn't work the way I expected it to.
Machine I'm working on: Windows
Experience with git: Beginner
Terminal: git bash
core.autocrlf: true
So let's begin with the first bit of confusion. I used the command echo hello > file1.txt in my working directory, then I also created a text file by opening notepad and saving it in the same location as my "file1.txt" and giving it the name "file_windows.txt". When opening both files on notepad, I saw a difference, "file1.txt" had "Unix (LF)" marked at the bottom of the notepad tab, whereas "file_windows.txt" had "Windows (CRLF)". I imagine the distinction was made since the first file was made with a unix/linux command in comparison to the other file which was created through the use of notepad and windows.
Now the problem arises when I tried adding those files to the staging area. When using the command git add file1.txt, I was faced with the following message:
warning: LF will be replaced by CRLF in file1.txt.
The file will have its original line endings in your working directory
I was a bit shocked since I thought that having core.autocrlf set to true would mean that git would make changes to the file by making sure "crlf" was replaced with "lf" when adding to the staging area, not the other way round suggested by the warning, of course the point of having that setting on was so that if let's say for example, someone on a linux platform with core.autocrlf set to false, would be able use that git repository without having to worry about some file having "crlf" instead of "lf".
Then when using the command git add file_windows.txt there would be no warnings as expected, since I imagine it is doing what it is supposed to do and replace "crlf" with "lf" when adding it to the staging area. What I am trying to get at here is that if there was for some reason to be a file that I'm working with that is in "lf", I wouldn't want it then switching it to "crlf" when I am adding it to the staging area, since there really wouldn't be a need to do so and it would probably not be beneficial.
Another thing to mention is that (although shouldn't be taken too seriously since I am a beginner using git so I don't know if it is because I am doing something wrong) when I commit both files, then use the command git checkout <commit hash> and then go open the files by start file1.txt (which opens them up on a notepad), I don't end up seeing the change which the warning stated it would make, it still shows as "Unix (LF)" and not "crlf" so it leaves me even the more confused.
Coudl someone explain what is going on please?
The warning "LF will be replaced by CRLF in file1.txt" means that it will be replaced by CRLF when you check the file out next. The file is indeed stored with LF endings in the repository, since all files subject to text handling are stored that way.
However, when you use git checkout, Git doesn't check out files which are up to date in the index. That's why you don't see git checkout modifying the files in the working tree.
This message is ultimately harmless, but it just warns you that you've placed a file into the working tree that does not use the line endings that you've requested, explicitly or implicitly, which means you may end up with different behavior next time you clone or checkout the repository. If all your tools handle any line ending gracefully, or you've properly configured your .gitattributes file to specify appropriate line endings, then you shouldn't have anything to worry about.
I typically like to type up my git commit messages while looking at the git diff.
I very much enjoy the output produced by this little perl add-on to git, and produces output that looks like this from git diff (this is a screenshot of git log -p but you get the idea:
Because of how it highlights out the corresponding parts of the lines that have changed it is very easy to see what's changed. Just wanted to share that because it does not look like a lot of people use it, and for me it beats the hell out of using an external separate diff tool or something like that, because this works over the terminal! It is also quite more unix-pipe-friendly in general than something like vimdiff though vimdiff is quite handy in a pinch as well.
Anyway, the show-and-tell is only tangentially related to the real question here, which is, can I set up a terminal window where I've got the git diff showing, but to have it be dynamic so that when I save a file it can refresh the git diff for me? Basically the idea is to have a terminal window serve as a real-time display of the exact changes I am about to commit, and this way I can just switch straight from my text editor to entering the git commit command while reading the entire set of changes, and to have this workflow also be a possibility on a Linux machine over SSH as well.
That would be a really awesome workflow, and I think a little bit of cmdline fu can get me there, but I'm not really sure where to start. It seems like OS X and Linux would require separate implementations. I found fswatch which might work for me, and apparently that is similar to inotify-watch on Linux. I shouldn't need to set this up on more than just my OS X dev machine, but like I mentioned before, having this capability over SSH would be epic.
Are there any other quick-and-dirty UNIXy approaches to this problem?
You would like something like "watch git diff". The "watch" command repeatedly runs a command and shows the first page of output.
You need more than the first page of output, and also you don't want to be moved to the top of the output whenever it updates - you want to constantly view the same offset in the diff until you scroll.
I haven't tried it but you might be able to use "screen" or "tmux" to provide a large virtual screen. (See https://serverfault.com/questions/50772/is-there-a-paging-version-of-watch.)
What's wrong with using plain built-in git commit -v which just shows you the full diff of the changes to be committed under the commit message? (And Vim highlights this diff just okay, with stock setup.)
I am wanting to commit some changes I have made, but somehow on my Cygwin system, bzr diff shows that every single file had the executable permission switched on ("+x"). How can I commit everything except any file permission changes?
In my case, the easier method (which I'm about to try) is to globally change all files to lose executable permission. However, I still would like a general answer to the problem of how to selectively not commit file permission changes.
You should be able to change the files to no longer be executable by running "bzr revert" on them. Alternatively, you could just run something like "chmod -R a-X ." to remove the executable bit from all files.
There is no way in Bazaar to only commit the content changes of a file and not the metadata changes at the moment.
Changing it globally is probably your best bet. It is also a problem when mounting fat32 partitions (eg. usb keys) under linux.
There is a bug for this. I got sort of halfway fixing it so that it will be auto detected, but dirstate was a bit difficult to work with and then I ran out of time.
I've got a file and a patch for it. I'd like to visually apply the patch, t.i. see how the changes proposed by the patch look in context, make some corrections, and save the resulting file.
What tool can do that?
Neither of the visual diff tools (i.e. meld, diffuse, diffmerge) do what I want: they don't work with patches, they merely merge whole files.
I really like Kompare. It is just a (very nice) graphical interface for diff.
http://www.caffeinated.me.uk/kompare/
sudo apt-get install kompare
Creating and applying patches
Kompare is able to create a patch file
which lists only the differences
between two compared text files A and
B. Further, Kompare can apply a patch
file which was created this way to an
original file A and, in this manner,
recompute the contents of the
corresponding file B. This is a
comfortable utility for passing a
corrected version of a file to a
friend who already has an older
version of the same file, because only
the (relatively small) patch file has
to be delivered and the receiver can
generate the corrected file by
applying the patch to the original
file.
The patches created and applied by
Kompare are compatible to patch files
generated or applied by the command
line interface diff utility, because
Kompare is in fact merely a graphical
front end to diff and the patches are
created and applied by patch, which
gets called by Kompare.
See use vimdiff with a diff file.
gvim original.file +'vert diffpa the.patch'
This will open GVim and split the window, with the original on the left and the patch applied on the right. You can then add, remove, or change hunks, and save the changes. (Well, if you want to create a new.patch you'll have to run diff again, but that's not difficult.)
You may use the emacs ediff mode.
It lets you see and validate each chunk interactively.
For what it's worth, I have this handy script in my ~/bin directory:
#!/bin/bash
if [ "$1" == "--text" ] ; then shift; fi
if diff --brief $1 $2 ; then
exit 0
else
emacs -fn 8x13bold --eval '(ediff-files "'$1'" "'$2'")'
fi
Another option: if you use Eclipse, you can generate and apply patches visually.
The idea with visual diff tools is that you can:
make a backup copy of the patched file (or a new pristine checkout of the whole tree)
apply the patch
use the visual diff tool to review the changes in context
make any desired change to the patched file within the visual diff tool.
Some tools, such as meld or diffuse will automatically diff against the previous committed version of the files.
The key insight is that you CAN apply the patch, they discard everything you don't like as long as you have a backup copy, or if you are working on a clean checkout.
If you feel more comfortable with reading and modifying unified diffs, and just want to have more context for the diff, emacs has a fairly unique feature, which is next-error-follow-mode while viewing a diff file (diff major mode). That shows the context of a diff line in the target file.
On platforms where Kompare (a fairly nice piece of software if KDE is your cup of tea), I agree that Eclipse is a great option.
I have consistently been a reluctant Eclipse user AND I am consistently impressed by how well the tools work (once the platform finally starts up).
On Fedora, I've got just about every front end installed for each of the main version control engines (SVN - also serving my Windows machines, Mercurial, git, etc.);
Meld is quite nice (no patch interface though).
Submerge works well also.
But since Eclipse does know how to apply patches and Working Copy project created itself once I figured out to create the project in the folder containing my working copy, it may become my favorite SVN front end.
I normally use GitExtensions (.NET and Mono) which also supports applying patches interactively. I hope you are already familiar with git.
Edit: Everything mentioned below this line doesn't seem to be available directly in KDiff3. And as I mentioned before: I haven't tried it yet.
GitExtension normally uses KDiff3 as diff tool, which is able to view patches.
http://kdiff3.sourceforge.net/doc/kpart.html
Using it for patches it has only a two window view, (edit) and doesn't support merging :( but it also supports 3 way diff on complete folders etc.
Actually I never tryed it with patches.
Does xxdiff do what you are looking for?
I'd use meld.
Create two copies of the files, one without and another with the patch. Use meld to compare them, and you can see exactly what the patch is changing and make changes as necessary.
Seriously, why is this so hard?