I´m really new using Git Bash so sorry in advance if my description is a little rough.
I was trying to use python inside Git Bash for windows so i followed this instructions: https://www.youtube.com/watch?v=M33oOq-c60s&t=2s&ab_channel=chinamatt
When I closed and try to re-open Git,it loaded for a few seconds and closed, without any error message,
Now I can´t make it load even unistalling and re- installing it, the only thing I notice is that at the top of the window it says usr/bin/bash --login i..
I guess it had to do with the '. ${HOME}/.bash_profile' ~ /.bashrc command, but I have no idea since
I´ve had never used {HOME} command before.
First, make sure your git bash works again, by removing any ~/.bahs_profile and ~/.bashrc
Second, consider, if you are on the latest Windows 10, to use WSL2, in which you will be able to install/use Python in a familiar Linux environment, as opposed to Git limited mingw/bash.
Related
Before re-installing Git Bash, I was using "MinTTY as default terminal emulator". I just wanted my git bash to be colorful! Reinstall, follow this stackoverflow answer. Then when I use the same Git Bash apparently my common commands which is already installed before like:
nvm
node
npm
code
Is all gone! How do I get all of my command list back? I have python running thought, because I wrote in .bashrc alias python= winpty python. Are there any way to add those commands without adding them one by one through PATH environment variables? Or do I have to keep adding my list in .bashrc?
Thank you!
thank you for the attention.
Apparently, I was using the first CLI that is offered by the installation launcher after the installation is done. With the same CLI, I was so confused why does this CLI doesn't run my usual commands. However, turns out it can be solved by simply closing and opening a new CLI. Then everything went fine.
I sure felt so silly. Should've tried restarting it from the beginning.
The documentation says plain as day that VSCode does not come with git, that it leverages your machine's git installation and you must install it.
HOWEVER, it worked just fine for me. I only had github desktop and I am absolutely positively sure that I did not have git for windows installed and github desktop did not place itself in my PATH. (Technically I did have git on Bash on WSL but I know vscode isn't/can't access that). And yet it worked just fine for the longest time.
So, my question is, did vscode come with its own git executable? I ask because ever since I set up 2 factor auth on my github account I've been having to manually log in each time I push, it doesn't use my SSH keys stored in username/.ssh like git shell does.
Github Desktop installs git for you, typically located "C:\Program Files\Git", which is what VSCode, in your case, is most likely using.
If you refer to the answer from this post:
VSCode Terminal + Git Bash "command not found" for any command
it shows the settings (settings.json) that you need to add to allow for git bash and login to be used.
Hopefully this helps!
I have a repo that has two branches, which i would like to work on simultaneously.
After some reading I found git has a script git-new-workdir.
Im trying run use the script from the git for windows bash but get the following error.
$ git-new-workdir
sh: git-new-workdir: command not found
How do I use this script on windows?
Due to some of the commands in the git-new-workdir functions not existing on windows, the script won't work.
I have found this windows port of the script. Works great for me.
https://github.com/joero74/git-new-workdir
Git 2.5 (Q2 2015) will replace contrib/workdir/git-new-workdir with an official native Git command which works on any OS (including Windows).
The release notes mentions:
does not rely on symbolic links and make sharing of objects and refs safer by making the borrowee and borrowers aware of each other.
That is because the multiple working trees are "linked", or actually recorded in the main repo new $GIT_DIR/worktrees folder.
See "Multiple working directories with Git?" for more.
On my installation, the script file is located in /usr/share/git/contrib/workdir/git-new-workdir.
Perhaps if it's not installed in that version of git, you can just download its raw form and run it with bash /path/to/git-new-workdir. At your preference you can also install it in /usr/local/bin changing permissions when necessary.
I am really enjoying my time with git.
I'm operating on 2 machines with what I thought were pretty similar setups
On my Laptop
When I type "Git help SomeCommand" from the CLI, my laptop launches the html help in my browser and I am free to read up on whatever help element I asked about.
On my Desktop
The CLI responds as if is is going to do the same, but no browser is switched to and no help is launched
What can I do to get my help back on my desktop?
Note: I'm running the bash shell through console2, but this problem appears to affect the default bash shell run via the context menu in explorer just as much.
I just recently had the same problem, browser wouldn't launch.
I'm running Git 1.9.2.msysgit.0 on Windows 8.1. Default browser - Chrome.
None of the solutions above worked for me. But I simply went to the html file in the explorer, and double-clicked it. Windows then asked me what app to use to open it, and I chose chrome.
Now usual git commands work and open the help html files in Chrome.
As mentioned in the msysgit bug report 445:
Git has it's own tool called "git web--browse" that invokes the web-browser.
Set the environment GIT_TRACE to 1 to see what processes are started, and with what
command-lines.
So that can help debugging the issue.
A temporary workaround (which might not be effective in your case) was:
As temporary workaround one can rename all git-<command>.html to git<command>.html in his <Git>\doc\git\html directory.
The git <cmd> --help suggested by Andy seems to have helped though, and must have "reset" something.
You can configure a web browser to be used to open Git's help files independently of the system's default program assigned to open .html files.
To check if it's set and to what value, simply run:
git config web.browser
To set it globally for all repositories, for example to chrome, run:
git config --global web.browser chrome
You can also set it per-repository, in that case run it inside a repository and without the --global parameter:
git config web.browser chrome
It works automatically if the specified browser's executable is in PATH. If it's not, you may set it manually:
git config browser.<name>.path <path-to-browser-executable>
...so for Chrome browser, it may look like the following:
git config browser.chrome.path "c:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
See the documentation for details.
It seems that this bug went away when I upgraded to the latest version of msysgit (1.7.6 from 1.7.3)
I have this problem currently, and the git <cmd> --help technique doesn't fix it.
I have however found that doing
git help -w <cmd>
Will actually open the help file in the browser, so this is a useful workaround.
I had the same problem (browser wouldn't open), then I realized it's probably because our laptops at work are "least privileged access", meaning we're logged into our Windows systems as standard users. But for development work, including the command window I'm doing git commands from, I'm running as a different user who has local admin privileges. So it actually was opening the Chrome browser, just not in my "logged in" desktop session where I could see it.
To work around this, I ran another copy of Chrome as that user (by Shift-Right clicking on Chrome.exe and running it as the same privileged user that my command prompt is running as). Once that instance of Chrome was running on my desktop, I returned to the command prompt and re-ran the "git help " and it properly launched a new tab in that instance of the browser that was running as the same user my command prompt was.
Stab in the dark: I've always done git <cmd> --help. Does that work?
edit: For future reference. This appears to be what fixed the OP's problem. Running git <cmd> --help seemed to have cleared out something so that it works as specified now. If only I knew the how/why of it...
This set up is current, working and the convention.
It's most likely because you are using the default Git that comes with MacOS called Apple Git which is outdated.
run git --version and check against the Git website.
Install Git using brew install git.
To make sure Homebrew installs take precedence over MacOS installs add the usr/local/bin path to your .zshrc or .bash_profile. export PATH=/usr/local/bin:$PATH. (*Btw, you should use this path also for using Python 3 instead of MacOS Python 2.7 and many other applications).
To make sure all of this is activated do source ~/.zshrc or source ~/.bash_profile. Or simply restart Terminal.
Test it. git help -w commit. A browser window will open.
I'm having trouble getting post-recieve and post-commit hooks to work correctly with msysgit (Windows 7 Pro/32 and Ultimate/64). For post-commit hook I get the above error if I commit from either git-bash or the console, but it works fine if I commit through git-gui. For a post-recieve hook, all three give the same error.
I'm thinking this is some sort of permission or path error, but don't really have any clue where to start here.
Add the SHEBANG to the first line of hook, like so:
#!/bin/sh
echo "executing post-commit"
exit 0
This had me stumped for a while as well and I saw that adding the shebang fixed it. In SVN world, while in *nix we have a "pre-commit" script and in Windows we had "pre-commit.bat" and SVN automatically picked up the bat file in Windows. Git doesn't seem to pick up a pre-commit.bat ( or any hook ) and adding the shebang to the hook file worked.
I'm using SourceTree and git LFS and had a similar issue: cannot spawn .git/hooks/pre-push.
The fix was to delete the pre-push file (opening it revealed it was badly corrupted) and restart SourceTree at which point it regenerates the pre-push file and everything is back to normal.
If you have the SHEBANG and it still fails, make sure you have <path_to_git>\bin set in your path environment variable.
You'll probably also have <path_to_git>\cmd if you installed it to work from the command-line.
This is an old question, but I've been fighting with this exact problem and this SO question popped up, so I thought it worth the effort to record what worked for me.
In short: I needed to run Apache as a regular user instead of Local System. This was on a legacy test VM I was playing with, so it was only running Windows XP, but it appears that at least on that platform (and possibly others), msysgit just doesn't work properly when running under the Local System account (presumably the root filesystem isn't mapped properly). As a result, no shebang line will work as git-http-backend simply can't execute any msysgit binaries (even with absolute Windows paths).
Switching Apache to run as a regular user account fixed this problem completely. Obviously you need to ensure that the user Apache is running as has permissions to read/write the git repositories, but beyond that, just make sure your shebang line is #!/bin/sh and everything should be copacetic.
Lastly, yeah, this is a big hammer. Ideally you'd be able to use something like suexec on Windows, but a quick googling doesn't indicate an obvious path forward, there. Of course, if anyone has any ideas, I'd be interested.
For now, this works for me, but it doesn't seem ideal.
Got this in a repo using LFS, got rid of it with git lfs update --force
If someone, like me run into a similar problem with accessing git repositories through apache, you should set the PATH in Apache config, like:
SetEnv PATH "c:/Program Files (x86)/Git/bin;"
Using tortoisegit and LFS, for me just had to remove the files inside of the .git/hooks folder.
If you are using Android studio, you can remove this error by un-check the checkbox "Run Git hooks":
For me, removing a comment line on front of the shebang line fixed the error. Oddly, the script ran fine from the shell, just errored out when run as a hook.