I'm using on my desktop native windows emacs 24.2 configured to use cygwin bash.
When I run SVN from cygwin bash everything works fine. It remembers my authorization credentials and connects to a repository. But when I try to run any version-control command from within emacs I always get the following message:
svn: E170001: Unable to connect to a repository at URL
'https://address.to.repo' svn: E170001: OPTIONS of
'https://address.to.repo': authorization failed: Could not
authenticate to server: rejected Basic challenge
I tried also connect with PSVN interface which also ends up with the same error message. It is somehow strange that it does not work the same way from cygwin terminal and emacs. Any help on this would be appreciated.
Solved now. The problem was that Emacs NT cygwin integrated was still using windows HOME path instead of using cygwinized HOME directory.
I think the full answer should be something like this:
SVN depends on the HOME path to find its per user settings (as most unix programs).
In cygwin that varible has something like "/home/pablo".
"/home/pablo" is really translated "drive:\cygwin_dir\home\pablo"
Emacs-nt grabs its HOME from the windows environment so it is a different HOME than cygwin's
emac's vc-svn uses the wrong path to look for its settings.
So there are two solutions (maybe more):
Make emacs-nt use the cygwin's HOME (so thats what cygwinization means!! :O), you need setup-cygwin for this, but specially you need one script it depends on cygwin-mount. So emacs-nt can understand cygwin's path "style".
(not recomended) The other way around, which is what I did, make cygwin use the window's HOME through a soft cygwin link. ln -s /cygdrive/c/Users/pablo/Roaming/ /home/pablo
Make a soft link so the cygwin's subversion dir points to the windows one ln -s /cygdrive/c/users/pablo/AppData/Roaming/.subversion /home/pablo/.subversion
The second solution WILL lead to cygwin's ".bashrc" not executed. So environment variables and aliases defined there won't be define. I still think that it can be done, but I don't have the proper cygwin knowledge needed to tweak that solution. So right now I'm using the solution number 3.
Related
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'm gonna to use vagrant on my windows desktop to develop Laravel project. I have followed all the steps to do that. But it has been failed to create homestead.yaml using bash init.sh command.
Below is the error :
Fakhreddin#Lenovo-PC3 /cygdrive/d/laravel-vagrant/homestead
$ bash init.sh
cp: unwritable ‘/home/Fakhreddin/.homestead/Homestead.yaml’ (mode 0500, r-x------); try anyway?
I'm using Cygwin for simulating Unix terminal in the Windows.
(Copy of the comment I wrote above)
Never used Cygwin in my life, but what I would try is to run it as Administrator and re-try.
Otherwise, you may want to consider changing console client. For example, if you install Git, you should be able to use Unix commands via standard Windows console.
I would seriously point the fault at Cygwin, or its settings. I am a member of a team in which all of us run Homestead on Windows 7, with no problems at all. The difference is, we use native Windows command line.
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.
There are many fine instructions about how to work with git under windows using GitBash.
I note that when git is installed, it offers the option of "set up for using git from the windows prompt", which puts git on the windows path.
Is there some way to set this up so that ssh authentication works?
At the moment I get "permission denied (publickey)" when I try to do git commands that access the remote.
(edit) I have set %HOME% to point to my Windows home directory, and there is a .ssh folder in there with id files that work under a gitbash shell.
I appreciate that the answer is likely "no, this is why GitBash exists". But - it would be good to know for sure.
If the answer is "no" it kinda makes you wonder why you would bother putting git on your windows path?
ssh access works fine from a regular DOS session.
You only need to define C:\Users\YourAccount\.ssh and add your id_rsa and id_rsa.pub there.
Launch your git session through git-cmd.bat, which will define %HOME% to your C:\Users\YourAccount: that is what will make ssh work.
This should put your msysgit/bin installation in your PATH.
I really recommend not installing through a msi (Microsoft Installer), but through a simple unzip of an archive (portable version "PortableGit-x.y.z-preview201ymmdd.7z")
And the OP GreenAsJade's comment points out the fact that GIT_SSH must point to plink.exe.
Well, maybe I have a process that seems to work.
If you use a passphrase during the generation of the keys, you'll have to type this passphrase after loading an ssh-agent and add the key to the agent.
Basically, the solution is: follow the instructions on this page:
https://confluence.atlassian.com/bitbucket/set-up-ssh-for-git-728138079.html
BUT, during the generation of the keys DO NOT TYPE A PASSPHRASE.
Obviously, it's 'weaker' from a security point of view.
But, the .bashrc script will work as expected (loading the identity on git bash startup).
You can use then the "start-ssh-agent.cmd" script located on Git\cmd folder. It will open a Dos Prompt with the identity loaded and everything will work!
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.