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>.
Related
When using vim-fugitive if you issue :Gstatus it splits the screen and gives you the would be git commit editor and you can move over different files that have changes and press enter to see them in the other half of the screen. I believe it is like issuing :Gedit .
I then need to issue a :Gdiff manually to split the editor in half and see the side by side diff of the file to review and or stage it.
My question is is there a way to make it automatically go to :Gdiff when I press enter, while my cursor is on a file name that has changes.
Basically trying to save some time when going through a large list of files.
You can use D or dd inside the :Gstatus window to run :Gdiff on the file under the cursor. See :h :fugitive-:Gstatus or use g? inside the :Gstatus window.
For additional help you may wan to look at Vimcasts, which has some very nice fugitive.vim series.
A complement to command line git
Working with the git index
Resolving merge conflicts with vimdiff
Browsing the git object database
Exploring the history of a git repository
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.
Resolving conflicts with fugitive is great. After reading
Painless Merge Conflict Resolution in Git, I started to think how to display changes not only on a line-level but also on word-level.
All examples / cases are based on painless_git_conflicts_resolution repo. Hub was used to make git clone command more succinct.
Fugitive with disabled diff3 conflict style.
hub clone ryrych/painless_git_conflicts_resolution fugitive_no_diff3
cd fugitive_no_diff3/
git checkout beta
git merge origin/master
vim roses.txt
:Gdiff
The result is following:
Problem is that you can only see that all lines changed in some way. This example is very short, but how many of you spotted that of has been added in line 3?
RubyMine can solve that, though not always, leaving you more than often with diff marks, and without diff highlighting. Though on this screen shot there are no diff marks, the lack of 'contrast' makes it very difficult to solve that conflicts.
Fugitive with enabled diff3 + displaying common ancestor:
Show base in fugitive.vim conflict diff stackoverflow question made me try the accepted answer, but the solution wasn't an improvement.
hub clone ryrych/painless_git_conflicts_resolution fugitive_with_diff3
cd fugitive_with_diff3/
git checkout beta
git merge origin/master
vim roses.txt
:split
:Gdiff
[Ctrl][W][J]
:Gedit :1
opendiff as a mergetool
hub clone ryrych/painless_git_conflicts_resolution opendiff
cd opendiff/
git checkout beta
git merge origin/master
git mergetool
and voilà!
This, of course, solves the problem, but makes me rely upon an external tool that was only designed for one system. To sum up: is it possible to achieve something similar in Vim as in opendiff?
I've found that on my machine (running vim 7.4) all the diffs do highlight the differences within lines. The text from :help view-diff implies that this is standard behavior. It says nothing about turning the feature on or off, only that the hl-DiffText highlight group is used for "Changed text inside a Changed line"
I would try a different color scheme, or at least try and double check that your current color scheme defines an appearance for hl-DiffText
EDIT: Apparently, the given example is actually really bad for showing word-level differences. Every line has changes in multiple places, they're very short, and there's no lines that remain completely unchanged to provide context. As you can see in the screenshots, removing the conflict marker puts all the "all my base" lines at the same line number, and the word-level differences get highlighted. You might want to try with a more complex repo/merge conflict.
I have set vim as the svn editor.
Now, whenever I do 'svn ci', it opens up vim editor allowing me to enter the commit comments.
Below the comment section, there are set files which will be checked in. So, If I don't want certain files to be committed, I remove it from the list of files in the vim editor. But when I save and quit the vim editor, svn still checks-in the file I have removed in the editor.
Is this expected behavior? Or I need to set something in the svn configuration to make it work?
That list of files in the comments section is... well... just comments. It doesn't really do anything - it's just there to help you by letting you see what you are committing.
If you want to not commit certain files, you have to do it beforehand:
You can specify the files you want commit in the svn commit command instead of committing everything.
You can add the ignored files to your svn:ignore property.
You can use some GUI tool that'll let you visually select what to commit and what not.
There is some trick with changelists. Haven't tested it(I don't use SVN since it's crap), just found it in this answer when I googled.
Use Git with git-svn, and simply git reset HEAD the files you don't want to commit to unstage them.
The list in the editor is just informative; it tells you what will be committed but does not influence what will actually be committed (the relationship is the other way round). If that's not what you wanted, you have to kill the svn ci (typically by doing Ctrl+Z and then issuing the kill at the command line). To change what is committed, you need to list the files explicitly to svn ci; it only defaults to all known, modified files (i.e., those listed when you run svn status).
If the above way of working isn't to your taste, you might be better off getting one of the many GUIs that wrap around SVN. They almost universally make interactively selecting what to commit easier.
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.)