Currently writing a CLI application that provides a better wrapper for some Git functionality. As this is a CLI, the user uses their terminal to use the application.
What I need to be able to do is pipe the output of certain commands into "clean" and interactive sub-programs. For example, if the user has my UI up, but presses a key, I need my UI to entirely swap with that of git add --patch [file_name]. When the user is done (as that is a step-by-step process that eventually concludes) I need to swap back to my application's UI.
Problem is, I don't know where or what to pipe this output to. If I pipe it into the terminal, it clashes with the existing CLI app's stdout and that does not work.
A separate but related feature was to show diff logs. To solve this issue of a clean and interactive terminal for that, I piped the stdout into less and this worked perfectly. Just can't find a way to do that for something more complex like git add --patch.
Let me know if more details are needed. Mods got grumpy last time when I added (apparently too much) information, so this is super cut down.
Use a pager
Most git commands with multi-screen output will automatically invoke a user-configured pager like less or more.
For those that don't, you could explicitly pipe them to less. Less's default behavior is to restore the terminal when it exits.
git add --patch [file_name] 2>&1 | less
Use curses
Use curses to clear the screen at startup and restore it at shutdown. For example, in Python:
import curses
# Clear the screen.
scr = curses.initscr()
scr.clear()
scr.refresh()
# Application code here.
import time
time.sleep(1)
# Restore the screen.
curses.endwin()
(If you're not using Python you can probably find native curses bindings in whatever language you're using.)
Related
So, I'm working on a bash script to manage some of my version control commands that I've been doing manually via the command line. It's a long story why I'm doing this, and not just using one of the SVN tools out there. Short answer: I'm using both Git and SVN, with the same codebase, but for different purposes. These scripts allow me to execute all the commands at once.
Anyway, I've got the script going great. Everything works perfectly. My one concern is the times that SVN prompts the user for input. The big one I'm thinking about is merge conflicts. Whenever there's a conflict when its downloading files from the server, it prompts the user to take action about that conflict.
Ideally, I want to suppress all output from the SVN command during execution, and if there are merge conflicts, just postpone them and then tell the user at the end that such conflicts exist (the user can then go in and resolve them).
So, for the question: Is there a way to use bash to handle those user input prompts. To detect them, respond to them, and keep the process going?
For the sake of argument, let's work off of this simple SVN command. Assume that this command is in a Bash script, and when it is executed there is a merge conflict. What, if anything, can I do?
svn update .
Thanks in advance.
I use the
svn update my_checkout_path --accept postpone --config-option config:miscellany:preserved-conflict-file-exts=*
Where --accept postpone is to skip all auto conflict operations, and preserved-conflict-file-exts is to dissallow auto merge for all files.
Read more:
http://svnbook.red-bean.com/en/1.8/svn.tour.cycle.html#svn.tour.cycle.resolve.pending
http://svnbook.red-bean.com/en/1.8/svn.advanced.confarea.html
Update
To detect the conflict situation you can look for Summary of conflicts string in update output (if you sure you have use the english version).
I would like to dynamically debug a vim script. My current workflow is that I have the autoload plugin opened on a tmux pannel and the running application on the other pannel. I also set a tail -f vim.log and I launched vim with vim -V15vim.log. My goal is to monitor the execution of the plugin by adding plenty of echom.
Actually I was expecting something more useful that what I actually got.
I need to restart vim everytime I add a new echom
Nothing really useful is displayed on the log file vim.log
This method is obviously not the right one
I also tried to add breakpoints with breakadd func myfunc#test but it is not really working because the debugger windows interfers with the main window and change the way the plugin I am debuging behave.
How to improve my vim-script debug workflow?
HINT
I am actually trying to debug the vim-multiple-cursor plugin which does not work with a column block selection and virtualedit enabled. I would like to fix it.
:breakadd is the most powerful tool, but yes, its output and interaction may interfere with certain plugin actions, and trigger additional autocmds. It may help if you specify the optional [lnum] offset to only stop executing inside the function.
I need to restart vim everytime I add a new echom
It should be enough if you just :source the changed plugin script again. Scripts inside ~/.vim/plugin/ usually employ a multiple inclusion guard that you need to work around, though. My ReloadScript plugin can help with that.
Alternatively, the Decho plugin might offer a different approach worth looking at.
I am using Git Shell (the module for PowerShell) on Windows. It's the one that got installed when I installed Git for Windows. When I run a command that results in a lot of text such as git log I get a page of results and then a ":" at the bottom of the screen. I guess it's a continuation prompt because I press ENTER and get another screen of data. I can't usually recover to a normal prompt after this happens though. I get the text (END) at the bottom of the shell and it looks like it's masking the first few characters of whatever command I try to type and it even seems to act a little sporadic. I can't seem to figure it out. Any ideas?
Several of the git commands use a pager to allow you to view one screen full of information at a time. The one that come with git is usually less (more info). You can visit the link for common commands, but as you've found the most important is q to quit to get back to the command prompt. The next most useful one I've found is space to move to the next screen full.
You can change the pager used if you like in the git config file's core.pager field.
Just to add to the existing answers, the normal "windows" pager is more.com, which is usually referenced from cmd as simply more, but hidden by the function more with similar functionality in PowerShell. If you set
git config --global core.pager more.com
your problems should go away (although at the cost of features that exist in less but not more).
This is an old question, but I thought I would mention that git also provides a --no-pager option for you to leverage as well.
git --no-pager log
Hope that helps someone.
When I try to launch GitHub for Mac it immediately starts using up all of the free memory (as much as 1.6 Gb) until the application freezes. How can I limit the memory usage for this app?
I saw a previous stackoverflow post (titled 'Memory Issues for Mac App') that touched on this issue, and I've updated my .gitconfig file, but it isn't having any effect. It's not clear if if the app is even reading the config file or how it would be possible to determine whether it is or not.
Any suggestions?
My suggestion for git is to use it from the command line. It was designed for use from the command line. By not using it from the command line, you lose the following:
command history
scriptability
piping
tab-completion
lots of help and examples online
The first is a big one. You will ask yourself "What did I do to create a branch with tracking of another one?". On the command line you can hit ctrl-R and type "branch". Hit ctrl-R a few more times to iterate over each occasion that you used git branch. You will find what you did when you made that branch. Pressing up and down arrows will scroll you through previous and subsequent commands that you issued. You can even add the time and date into history and when you list the history you can see exactly when you did something.
Scripts are very useful for things you do repeatedly and the same tasks are tedious when done manually through the gui.
Piping is very useful as you can alter results from one command and pass them to another. Something I do quite often is
git branch |
grep 'filter for what I need' |
sed 'some funky transformation' |
xargs -n 1 -i{} git push -u centralrepo {}:public/{}
It's a made up example of how you might string together a few commands to automate some very time consuming task.
Tab-completion is great as it saves you time for having to hunt around for what branch exists or what file exists. It is context sensitive so when git expects a file to be listed, tab will fall through and start matching files underneath. When it's expecting a remote name, hitting tab a couple of times will get you a list of remote repositories. Partially typed branches or files or remote will get you a subset when you hit tab twice.
Getting help with git is important. It's got a steep learning curve. The majority of git's use is from the command line. So when you run into issues, google is very good at finding a solution quickly. Other git tools don't have this luxury and you may find yourself wasting quite a lot of time to find answers.
Is there any problem using both the GUI version of Github and the terminal version interchangeably? For instance, If I start a coding session using the GUI, then need to do something that I only know how to do from the command line. Then switch back to the GUI.
Are there any issues with that?
Both the GUI version and the command line (terminal) version can be used interchangeably. I use both myself on a Mac and haven't encountered any issues thus far.
There is nothing wrong with this, I do it all the time. The GUI is nice because it allows you to see all the newest changes very easily and well as do quick commit + sync. But I use the terminal for finer control like forcing a branch checkout
git checkout -b newBranch
I also switch to the terminal when I want to stash changes I have made and am not ready to commit so I can go to an older branch to fix something that is needed immediately (stashing stack is awesome!)
So yea, there is nothing wrong with this approach at all. Sounds like you know what you are doing, the terminal just give you finer control.