I only have one branch main but when I execute the git branch command, it took about 30 seconds to complete. Other commands like git status does not have this performance issue. What are some of the things that I can check here?
Git version is 2.36.0 running on Windows 10.
UPDATE:
Also opening up Git Bash is slow (around 20 seconds). I tried the solution https://stackoverflow.com/a/47542488/1160753. Git Bash opened up quickly after that change but the subsequent action of opening up the Git Bash is back to take approximately 20 seconds.
When Git Bash is executed under "Run As Administrator", git branch completed quickly. BUT that is not every single time. There are times that the same command takes 30 seconds to complete (this is without any additional branch)
Tl;dr
On Windows, when the PC is in a domain, make sure that the domain controller is reachable.
Details
The shell and command line tools that are distributed with Git for Windows are derived from the MSYS2 project, which is based on a variant of the Cygwin library. As part of the program startup routine, the library does several name lookups. When the system is registered in a domain, this lookup goes to the domain controller. In the case when the domain controller is not reachable, the lookup waits for time-outs. This causes the delays.
The results of the lookup is cached by Windows. Therefore for a short time, subsequent startups do not have to wait for the time-outs. But ultimately the cache expires and the next program invocation has to wait again.
The Git program, git.exe, is not based on the Cygwin library and does not need the name lookup. It can run without delay. However, many Git commands spawn a pager, typically less, which does suffer from the delay; therefore, it appears as if Git itself would be delayed. (Not that it matters; the user experience is bad either way.)
On top of that there are many other cases where Git runs a command line tool: hooks, textconv filters, ssh, etc. All of them can suffer from the delay.
EDIT: I am currently testing the following change.
Do NOT make this change to your system unless you know exactly what the security implications are.
I used mkpasswd and mkgroup to cache the current domain information locally:
mkpasswd >> /etc/passwd
mkgroup >> /etc/group
Then I removed duplicates from the files. (But /etc/group did not exist before these commands.)
This idea was taken from the Cygwin FAQ.
Related
I was working on bash to install a node module (which was my first command since opening it today). Didn't install quite right so since I knew that was my first command I went about looping back to that command and instead I noticed that it didn't stop going beyond that. Went as far back as November/December commands and stopped there. Is this a bug, a known bug, or something wrong with my installation?
Git version: 2.21.0.windows.1
Not a bug. That's bash saving history of sessions when you write exit. The amount of history you want to save when this happens can be set with the variable HISTSIZE.
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.
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.
I am using a bash script to run a number of application (some repeatedly) on a Windows machine through cygwin. The script contains commands to launch those applications, line by line. Most of these applications run for many minutes and many times I have observed that the i+1 th application is not being started even after i th application is completed. In such cases, if I press enter in the cygwin console on which the bash script is running, the next application starts running. Is it because of any issue with bash on cygwin? Or is it an issue with the Windows OS itself? Have any of you observed such an issue with bash + cygwin + Windows?
Thanks.
I think I have seen this before.
Instead of
somecommand
try
somecommand </dev/null
If that doesn't work, try
cmd /c somecommand
Or experiment with other redirections, e.g.
somecommand >/dev/null
Sounds like you may have a problem with your shell script encoding; DOS (and Windows) uses CR+LF line endings, whereas Linux uses LF endings. Try saving the file as LF.
What might also be going on:
When I was running Cygwin on a school laptop, I encountered a dramatic slowing of shell scripts vs. when they were running in a native Linux environment. This was especially apparent when running a configure script from GNU Autotools.
Check your path for slow drives. (From the Cygwin FAQ):
Why is Cygwin suddenly so slow?
If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist.
You might also want to check whether you have an antivirus program running. Antivirus programs tend to scan every single executable file as it is executed; this can cause problems for even simple shell scripts that run hundreds or even thousands of individual programs before they run their course.
This mailing list post outlines what is needed to pseudo-mount the main /usr/bin directory as cygexec. I'm not sure what that does, but I found it helped.
If you're running a configure script, try the -C option.
Hope this helps!
Occasionally, I'll get this behaviour because I have accidentally deleted the 'she-bang' at the top of the script, that is, deleted the #!/bin/bash on the first line of the script.
It's even more likely for this to happen when a parent shell script calls a child script that has the she-bang missing!
Hope this helps.
A bit of a long shot, but I have seen some similar behaviour previously.
In Windows 2000, if any program running in a command prompt window had some of it's text highlighted by the cursor, it would pause the command running, and you had to press enter or clear the highlighting to get the command prompt to continue executing.
As I said, bit of a long shot, but accidental mouse clicks could be your issue...
Install cygwin with unix style line breaks and forget weird problems like that.
Try saving your script as "the-properly-line-broken-style" for your cygwin. That is, use the style you specified under installation.
Here is some relevant information:
https://stackoverflow.com/a/7048200/657703
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.)