I haven't used the terminal in a few weeks, after running "Brew Upgrade" to upgrade/update all my packages, I started seeing "fatal: Refusing to point HEAD outside of refs/" after every command I run. I'm not that versed with the terminal or Git, so I have no idea what this means, please offer some suggestions/scenarios for why this may be happening.
I'll bet that you are using the fish shell, and upgraded to version 3.3.0 when you ran brew upgrade.
I'll also bet that you have a custom prompt running a command with error redirection using the circumflex diacritic (^). This is no longer a valid syntax :
Redirection to standard error with the ^ character has been disabled by default. It can be turned back on using the stderr-nocaret feature flag, but will eventually be disabled completely (#7105).
The solution is to replace all the ^ used for error redirection in your config with 2>.
For example :
git symbolic-ref HEAD ^/dev/null
becomes
git symbolic-ref HEAD 2>/dev/null
All credit to Njke on this GitHub issue.
Related
I have VSCodium v1.64.2 and have this error message in my integrated terminal window upon "Run/Start Debugging" command:
2022-02-14T17:14:16-06:00 error layer=debugger can't find build-id note on binary
This error message appears on all my programs inside the terminal window. I'm learning Golang (GO) and am new to the VSCodium (VSCode community) editor. My program runs fine with no errors in my Ubuntu terminal window as well as the integrated terminal in VSCodium.
Is there something I can do to correct the error? It's not interfering with my work, but I was curious. Thanks.
According to the issue of go-delve / delve (
#latestas delve#1.8.2of 2022/02/13), this problem is not addressed, so
install delve manually instead of installing with VS Code extension etc
# Install at tree head:
$ go install github.com/go-delve/delve/cmd/dlv#master
or
$ git clone https://github.com/go-delve/delve
$ cd delve
$ go install github.com/go-delve/delve/cmd/dlv
According to https://github.com/go-delve/delve/pull/2893, which has been merged, it should now just be a warning. You likely pulled delve before the merge, though, so updating should fix this.
For home office I need to setup a whole bunch of things, however I seem to keep running into issues with making git bash work properly in VSCode.
I have installed Git 64-bit Git for Windows.
Initially it didn't work at all until I added the following to my settings.json
"terminal.external.windowsExec": "D:\\SOFTWARE\\Git\\bin\\bash.exe",
"terminal.integrated.shell.windows": "D:\\SOFTWARE\\Git\\bin\\bash.exe"
with the second line saying it is deprecated, but it works none-the-less.
Now it runs but inconsistently. Running just the 'ls' command repeatedly it :
45% of the time won't run
45% of the time states 'segmentation fault'
10% actually work
The git bash app itself runs the commands with zero issues. I have read up multiple posts on 'segmentation fault' and seem no closer to the issue.
What I have tried :
Adding exceptions to AV (only running defender ATM)
re-installing git multiple times with admin rights to main and secondary drives
Win10 safe-mode installation
restarts before and after installations and installs
installing older versions of Git.
adding '*\Git\bin' to environment variables
I am really at a loss here and it works fine at the office. Perhaps I am missing something obvious.
Any help would be appreciated.
I found what I needed.
I needed to add in the settings.json file the following code :
"terminal.integrated.env.windows": {
"PATH" : "D:\\SOFTWARE\\Git\\bin\\bash.exe"
}
Having done that I thought I could remove the previous deprecated code :
"terminal.integrated.shell.windows": "D:\\SOFTWARE\\Git\\bin\\bash.exe"
But it seems it still was required.
I hope this helps someone as most of the references out there (that I could find) refers to the older deprecated code.
Note : seems now my 'vagrant' and 'npm' command wont run at all anymore
Originally from here.
Versions:
VSCode Version: 1.46.1
OS Version: Windows_NT x64 10.0.20161
Steps to Reproduce:
Install debian-dev-boilerplate inside WSL.
Setup powerlevel 10k.
Clone a git repo and enter its folder.
git clone git#github.com:DanielAtKrypton/debian-dev-boilerplate.git
cd debian-dev-boilerplate
You should now see something like:
Open vscode from zshell. By typing at the zshell prompt:
code .
At this point the bug is revealed when the terminal is opened for the first time inside vscode. At first glance, the terminal renders correctly the powerlevel10k theme. After half a second, the theme is deactivated as can be seen in the next picture.
Does this issue occur when all extensions are disabled?:
Yes. The first time vscode is launched, it installs a vanilla (with no extensions) vscode-server to the linux distro. And still the bug happens.
It is interesting to note that in prior vscode versions this functionality was working alright. For any reason I don't know this issue started to happen in the last couple weeks.
Additional Info:
Here is the log file when running the commands:
code . --log trace
exthost.log
Most likely Powerlevel10k has been installed and/or loaded from ~/.zshrc incorrectly. The screenshot of VS Code shows robbyrussell theme, so I surmise that you are using Oh My Zsh. To install Powerlevel10k on top of Oh My Zsh you need to follow these instructions:
Run: git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k
Set ZSH_THEME="powerlevel10k/powerlevel10k" in ~/.zshrc.
Try running grep -E 'ZSH_THEME|/powerlevel10k' ~/.zshrc. The output must be exactly like below.
ZSH_THEME="powerlevel10k/powerlevel10k"
If it's not, you need to fix ~/.zshrc.
The first time I used git bash, backspace was working fine. Then I installed Perl and didn't use git bash for a few days.
When I use backspace in git bash now it doesn't work correctly.
For example, trying to remove the second s and everything after it in ussers:
Now when I use the backspace this happens:
Can anyone help?
I had this same problem today after switching to mintty with a fresh version of git. In my case, it was an old .bashrc file I'd been carrying around for many years with the line export TERM=ansi. After removing that and starting a new bash, everything works again.
More generally, to debug, I was suspicious of all the dot-config stuff in my home directory--so I moved things like .bash_profile, .bashrc, .inputrc, etc. into a temporary directory where they wouldn't be read by bash. Then, I started bash and saw that it worked. I mention it because, if it isn't specifically the TERM issue I had, you might be able to debug using the same technique.
Not sure if this is the same issue.. But I ran into the same after upgrading git
This helped me.. Just enter TERM=XTERM in the bash
I got this from an issue log in github..
screenshot
Just in case people run into a capitalization issue please type TERM=xterm-256color directly into git bash and hit enter. This fixed my issue.
Right click on the menu/title bar of git bash, select options, click on terminal from the options on the left, under the 'type' dropdown, select 'xterm', then apply and save.
Now open a new git bash and it should work :D
I'm using ssh to connect to a remote server. On the server there is a git repo called MRFLSSVM. However, when I execute magit-status on:
/ssh:qmServer:/home/Chang/qmCodeLab/MRFLSSVM/
Magit asks me to Create repository in /ssh:qmServer:/home/Chang/qmCodeLab/MRFLSSVM/?.
Any idea how to let magit recognize that repo? (I've already installed git 2.10.0 on /usr/local/git and configured my system (CentOS) to use it by update-alternatives)
-----------Edit------------------------------
Error (magit): Magit requires Git >= 1.9.4, you are using 1.8.3.
If this comes as a surprise to you, because you do actually have
a newer version installed, then that probably means that the
older version happens to appear earlier on the `$PATH'. If you
always start Emacs from a shell, then that can be fixed in the
shell's init file. If you start Emacs by clicking on an icon,
or using some sort of application launcher, then you probably
have to adjust the environment as seen by graphical interface.
For X11 something like ~/.xinitrc should work.
If you use Tramp to work inside remote Git repositories, then you
have to make sure a suitable Git is used on the remote machines
too.
Error (magit): Magit requires Git >= 1.9.4, but on /ssh:qmServer: the version is 1.8.3.
If multiple Git versions are installed on the host then the
problem might be that TRAMP uses the wrong executable.
First check the value of `magit-git-executable'. Its value is
used when running git locally as well as when running it on a
remote host. The default value is "git", except on Windows
where an absolute path is used for performance reasons.
If the value already is just "git" but TRAMP never-the-less
doesn't use the correct executable, then consult the info node
`(tramp)Remote programs'.
This problem seems to be tramp is not using the correct git on remote server. I've tried to change magit-git-executable to usr/local/git/bin/git which is the path both of my local and remotes installed git. But this still doesn't work.
Any ideas to solve this? Thanks!