Whenever I execute git log command it cannot be terminated. If I do Ctrl + C it exits paging environment but if I start to type anything it starts git log command again.
as mentioned already, git log -X will limit your output to the last X commits.
Git log and other git commands invoke the less command. This is the pager. To get help with the pager, type ? or h when looking at the output. You will now see the help for the less command. Quitting less is easy, just type q.
If you don't want log to use a pager utility, you can instruct git not to use it with:
git --no-pager log
Git log has a lot of options. To get a quick overview of what has happened, I use
git log --graph --oneline --decorate --all
Decorate can be set to be enabled by default through config so you don't have to issue it.
If you think that's a lot to write on the command line, you're right! Bash has a quick remedy for that: CTRL-R. Press that and start typing 'graph'. You should get the last time that you typed that long command. This is one reason I don't bother with git aliases; it's easy to search your command history which persists from session to session.
Further, you can limit the output of git log to a particular author or particular date range, etc.
Have fun exploring and stick to the command line. It's what git was meant to be used on. You will also be introduced to a lot of excellent bash techniques that will help you a ton as you get going further with git.
You can limit the number of commits to be shown with:
git log -n 10
To limit only to the last 10 commits.
You can use also some kind of graphic interface for git, like gitk or tig or git-cola.
Check for other gui clients here.
Related
I'd like to be able to occasionally use a different editor when writing commit messages. I've found plenty of answers on how to change the default editor, but I don't want to change that - VIM is normally fine. What I'd like is some option like git commit --editor=<editor_name> where <editor_name> is the editor I want to use when writing the commit message for that commit only.
The only thing I've found that is similar to what I'd like is opening a new file with <editor_name> <newcommitfilename>, write message, save and close file, then use git commit -F <newcommitfilename>.
Is there an easier way to achieve this?
Thanks!
All Git commands use the form:
git <verb>
You may insert options before the verb, e.g.,
git -c core.pager=cat show
The -c option in particular takes a configuration item name, such as core.pager, core.editor, user.name, and so on, and a value, joined with an equals sign = like this.
Since your goal is to use a particular editor, git -c core.editor=whatever commit does the trick.
As several commenters noted, there are other ways to do this. For the editor in particular, the environment variable $GIT_EDITOR overrides core.editor, so:
GIT_EDITOR=nano git commit
runs git commit with GIT_EDTIOR set to nano for the duration of the one command (assuming POSIX-style shell).
This question already has answers here:
Git branch command behaves like 'less'
(9 answers)
Closed 11 months ago.
I'm a little confused with the following behavior of git commands in the Windows Command prompt.
This shows a result comparable to VIM (I think) with interactive list
git branch -a
Result is something like the following and I've no idea what key-combinations to use to scroll through the output (I did notice that q ends the output).
But this shows a "normal" result by just dumping the output to stdout
git show-ref --tags --heads
which is what I prefer:
How to make all output be just dumped to stdout?
I'd prefer if all commands work the same way. Esp if I want to automate a git command in a batch script or something, I cannot use some kind of interactive shell.
I noticed that this behavior seems to be caused by the TERM=msys environment variable setting, which, if absent, behaves the same. I don't know if there's a different setting I can use.
In the end, while the colored result may be fun, I can get that by using Git BASH. But when I run the commands directly from the Windows Command, I'd expect them all to just echo the output to stdout.
I can't remember that this was the behavior previously, so my guess is that I installed something that f'ed things up ;). I'm on Windows 10 for this machine, git, bash etc are latest.
This is what git calls a pager. You can disable it for a particular command with:
git --no-pager branch -a
(Note that --no-pager goes between git and the subcommand, because it is a global switch).
If you want to configure your system so you don't have to remember that, from man git-config:
pager.<cmd>
If the value is boolean, turns on or off pagination of the output of a particular Git subcommand when writing to a tty. Otherwise, turns on pagination for the subcommand using the pager specified by the value of pager.<cmd>. If --paginate or --no-pager is specified on the command line, it takes precedence over this option. To disable pagination for all commands, set core.pager or GIT_PAGER to cat.
That is, you can disable the pager for git-branch only with git config --global pager.branch false, for example.
And if you want to disable it for all commands do git config --global core.pager cat. Or you can try to set the environment variable GIT_PAGER=cat, of course.
I'm using cygwin under Windows to do some command line stuff. One of the commands I use sometimes is git stash. Since few weeks I always get this error when I use it: Cannot save the current index state
I also tried it in other projects, so it is no project related issue. The history is not broken or something like that. I don't use it often so I don't know when the issue started.
The error is thrown on line 110 of the git-stash file. That's why I debugged the two lines before.
$(printf 'index on %s\n' "$msg" |
git commit-tree $i_tree -p $b_commit)
When I echo the first command it outputs my last commit. This seems ok. When I output both commands piped it is empty, so maybe something is wrong with "git commit-tree $i_tree -p $b_commit". I google a long time but was not able to find a solution to this issue.
Cygwin Git version: 2.14.1
Cygwin x64 version: 2.8.2(0.313/5/3)
First, check if the issue persists with bash (the bash packaged with Git). Make sure to set your PATH in order to:
no include cygwin
include git/bin, git/usr/bin, git/mingw64/bin: see this example.
Working with a simplified path (for testing purposes) is important to make sure there is no side-effect from any other software.
Second, try and add a git status in the git stash critical lines, to see if the Git repo status reveal anything suspicious.
I'm using Github and Git bash on my Windows PC (running XP).
On Ubuuntu I'm happyily using git grep to plough through my code, but every time I call something like:
git grep "some text in my repo"
on Windows I get the results and afterwards I'm stuck with the bash window showing all kind of things [END], ~, [RETURN]... whenever I try to enter something.
Question:
What else besides CTRL+R, CTRL+Q, FN+END, Q, ESC can I try to not having to force-close and reopen git:bash in order to continue to work.
Thanks!
EDIT:
This is what I mean:
As soon as I start typing, the [END] string re-appears (or 50 lines ~) and I cannot write any command on Git, because whatever is in the way swallows half of what I'm typing.... nice description...
I was wondering about this also after installing git and running git bash. It seems "git grep" pipes commands through "less".
Solution: Just type q.
Is git launching less (or something similar) so up/down arrows on your keyboard scrolls through the matches? If you don't want that, try the instructions from https://stackoverflow.com/a/12166923/972216:
set GIT_PAGER=cat
Would disable it for your console session once, or
git config --global core.pager cat
to disable it for your account.
I've got Git for Windows setup (msysgit) and it was working fine for the last few days and today I've encountered an odd error.
When issuing a Git command in the Windows Command Prompt or in the Git Bash that comes bundled with msysgit, I get a strange '(END)' line appear and then I cannot issue any other comamnds.
At this point all I get are system beeps.
Any ideas?
Thanks, P.
Git want to show more than one screen of information to you, to do so it call the standard unix pager program less. Just type q to return to the prompt when you no longer want to navigate in the output.
j move one line down
k move one line up
<space> move one page down
b move one page up
h show the help
If you want to use git efficiently you should learn the basic unix tools. Even if git build and run on windows it's pretty much an alien software on the platform.
If you don't want less just replace it with another pager in the configuration. If you don't want a pager at all just use cat :
git config --global --add core.pager cat
Press q to exit the pager (which is less in git by default).
I first came across this question when I was looking for the same thing; to not have to exit out of the log command. I have since found the answer I like, so even though it is well after the original asking I will add this answer to provide an additional solution that I didn't find quickly in my own search.
Others have stated why the (END) is present -- the results are being piped thru a pager, one that can be configured for a different pager.
However, I sometimes don't want it to stop at all; because I've specified other options that do the limiting. I found that for this git has a global option --no-pager to turn off the whatever pager is defined in the config file.
This global option is on the git command itself, is available for all subcommands and is placed before the subcommand like this:
git --no-pager log
Git is using the "pager" called less, which allows you to scroll through large amount of program output easily. However, the default settings on Git for Windows seem to be to keep the pager running even when there is less than one screen of output.
Here is the default setting I had before, which would always show the (END) and wait for you to hit q before returning you to your prompt:
$ git config --get core.pager
less -+F
You can change the behavior so that less will only keep running (and take control of the keyboard) when there is more than a screenful of output by changing the option to -F instead of -+F.
Fix the pesky pager with
$ git config --global core.pager "less -F"
(The -+X option syntax for less is documented to reset the -X option to its "default", although that is not the behavior I observed with -+F since removing the option altogether was equivalent to -F, not -+F.)