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.)
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 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
I have a file.patch file generated from someone else. I want to review the patch file, but I would like to be able to apply my own git color config to the file.
I may not currently be in a git project directory and I may not even know what repo the patch file came from, but I just want to see basically context/additions/deletions colored with my normal git colors.
I'm looking for a pipeline solution rather than some external library. Something like:
git --please-color-this file.patch | less
colordiff < file.patch | less -R
The 'less' command is optional but I find it useful, e.g. for scrolling, searching.
less is not the program you're looking for, the colors are not stored in the file and less doesn't understand the diff format. Instead, use a tool that understands the diff format, for instance text editors such as vscode or vim. The best program is the program you currently use for merge conflicts.
I use git and gitk a lot. Recently, I found some enthousiastic posts about tig and decided to give it a try.
It looks great for viewing the repository, however changing the repo with tig seems difficult if not unworkable.
The problem I am facing is that tig fails to start an editor for external commands, thus making it impossible to continue with the action.
For example, if I select a commit and issue
!git commit --amend
I get a screen saying
vim: Warning: Output is not to a terminal
Only ^C gets me out, thus stopping tig as well.
What can I do to configure this properly for either tig or git in order to get this working?
thanks in advance,
Ruud
The main way to start external commands is via keybindings and what in Tig is referred to as user-defined commands. For example, to amend the last commit you can add the following to ~/.tigrc after which pressing + will put you right into Vim:
bind generic + !git commit --amend
There are several variables for the browsing state, which can be passed to external commands, such as %(commit) and %(branch) as well as %(prompt) for asking for input, for example when creating a branch.
For reference, the !<command> allows to open the output in the pager, for example !git show 3e3abcd and as such is more like Vim's :r!<command>.
I just switched to a new (already configured) development box.
Now git behaves differently, with some commands.
Let me try to explain it:
before (on the other machine) when typing git log I was getting the list of commits in my terminal. So I could just scroll up and copy/past SHAs as many times as I wanted.
now (on the new machine) when typing git log I get a new buffer in the terminal, where I'm shown the commits. Now I have to exit/quit the result display pressing Q.
After that the buffer is cleared and I come back to the terminal, but I DO NOT have any logged/buffered result in it; so I CAN NOT scroll up to see the result of the command.
To be more clear, now many git commands (diff, log, reflog, show, etc.) behave like vim or man, where the output of the command is in a separate buffer and the user explicitly needs to exit this view to come back to the shell.
Is that some kind of git configuration? Maybe a specified default editor? Or maybe is a operative system setting?
I was not able to find information (or the right keywords for searching the information) for solving this issue.
I hope this will be useful to others (and more easy to find with non-specific search keywords!).
The solution seems to be about setting the pager of git.
The pager is the command that is used to display the git commands output.
In my case trying to run:
git config -l
was not showing me any evidence of the current setting. But coming from a previous version I just assume that the default value for the pager has been changed to something different from less recently.
And with the new pager the screen is cleared after pressing Q, not allowing the the terminal buffer to maintain the output result.
Anyway I was more comfortable with the old pager: less, or no pager at all.
So I reset it with the command:
git config --global core.pager ''
This will use no pager and will always show the output in the shell, allowing you to scroll up and copy/paste/check any part of the git commands output.
But is not nice whith git log because it will scroll down to the end of the list and will show the less recent commits.
So the perfect solution (for me) was to set it to less, BUT ADDITIONALLY I had to pass some options to it for defining the exact desired behaviour; so now I'm shown the list from the top, and then I can scroll up and see everything I output.
The final command I used is:
git config --global core.pager 'less -FRSX'
(as explained on the section Better pager defaults of this Atlassian documentation page)
The fundamental in those settings is -X that prevents the screen from being cleared. While -R allows to maintain a colored output.