Fix msysGit Portable $HOME location

Question

I have successfully installed and configured msysGit Portable on my flash drive, and have used it to pull and push GitHub repos. However, I seem to always have to kludge the SSH support.

Specifically, in order for SSH to find my key files, I have to follow these instructions to start a second instance of ssh-agent and then ssh-add my key every time I run git-bash.bat.

Using the output of ssh -v [email protected] to debug I see that msysGit defaults to my Windows user directory to look for keys. It can't do that; I need it to look in its own directory on the portable drive.

How can I force $HOME to be the program's own folder?

Update for broken Vox link

Instructions from this page are similar to the now-broken link I originally posted. Quoted below. Also here's the webarchive of original Vox article.

However, if you try this and get:

% ssh-add
Could not open a connection to your authentication agent. 

then your session is not running under the ssh-agent. You can get around this by restarting a new shell under the agent by running:

exec ssh-agent bash 

where you can replace bash with the shell of your choice. Once you do this, you should be able to run ssh-add to load your key for that shell.

Answer 1

The command used to launch git bash is:

C:\Windows\SysWOW64\cmd.exe /c ""C:\Prog\Git\1.7.1\bin\sh.exe" --login -i"

I just tried the following in a DOS session:

C:\>C:\Windows\SysWOW64\cmd.exe /c ""C:\Prog\Git\1.7.1\bin\sh.exe" --login -i"
VonC@XXX /c/
$ echo $HOME
/c/Users/VonC

By default, $HOME$%HOMEPATH%, but if I force %HOME%:

set HOME=/another/path

and then launch the same bash session:

C:\>C:\Windows\SysWOW64\cmd.exe /c ""C:\Prog\Git\1.7.1\bin\sh.exe" --login -i"
VonC@XXX /c/
$ echo $HOME
/another/path

So if you wrap the bash call by a script setting the HOME to:

• %~dp0 : the path of the wrapper on your USB key
• or %~d1\your\path: with %~d1 being the drive letter (of your usb key if your wrapper is on it)

, you should be able to force HOME to whatever value you need.

---

Note (November 2011): since then, the OP dgw has written his own wrapper:

git-bash-portable.bat:

@echo off
rem Copyright (C): 2010 Voyagerfan5761
rem http://technobabbl.es/

set USERPROFILE=%~dp0
set HOMEDRIVE=%~d0
set HOMEPATH=%~p0
set HOME=%~dp0
set HISTFILE=%USERPROFILE%.bash_history
rem set BASHRC=%USERPROFILE%.bashrc

git-bash.bat

The article "Portable Git for Windows: setting the $HOME environment variable to allow complete portability (including SSL keys and configuration for use with GitHub)" also add useful information.

However, if you install Git on a portable drive, you'll want your settings to travel with the installation—which obviously they won't if it is looking for them in a folder which may not exist on other computers.

So, what we need to do is tell Portable Git to treat a specific location within its own folder as the home folder; that way we can copy the whole Git folder anywhere we like and the settings will travel with it.

Answer 2

Setting the home dir

The solution with a git-bash-portable.bat wrapper opens another Windows CMD window for me that stays in the background.

Another, more native solution is to adjust /etc/profile and set the HOME var there. Just add the following lines to the end of /etc/profile, myuser beeing your virtual username:

# end of /etc/profile
export HOME="/home/myuser"
cd

This sets the proper HOME directory and cds into it. Then the startup mechanism, like loading all files from /etc/profile.d works correctly and you just start git-bash.exe with a doubleclick.

Of course you have to create your home directory for this to work. Start git-bash and create it:

mkdir -p /home/myuser

Starting or reconnecting to the agent

Regarding the agent, it usually has to be reloaded with every git-bash shell opened. A solution to get an independent agent spanning all git-bash windows is to include the following little script ~/.mgssh in the startup. It stores the agent env vars in a file agent.env in the .ssh directory. Any new shell reads the file, checks if the agent is still running and connects to it. If it is not running it starts the agent and rewrites the agent.env file. Make sure your .ssh dir exists.

# cat ~/.mgssh

agentfile=~/.ssh/agent.env

agent_load_env()
{
  test -f "$agentfile" && . "$agentfile" >| /dev/null;
}

agent_start()
{
  (umask 077; ssh-agent >| "$agentfile")
  . "$agentfile" >| /dev/null;
}

agent_load_env

# agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2= agent not running
agent_run_state=$(ssh-add -l >| /dev/null 2>&1; echo $?)

if [ ! "$SSH_AUTH_SOCK" ] || [ $agent_run_state = 2 ]; then
    agent_start
fi

# uncomment this, if you want to add a key on agent startup
#if [ "$SSH_AUTH_SOCK" ] && [ $agent_run_state = 1 ]; then
#    ssh-add
#fi

unset agentfile

Now source the .mgssh script in your .bashrc:

# cat .bashrc
. ~/.mgssh

# ... more .bashrc content

Found this on GitHub:

https://help.github.com/articles/working-with-ssh-key-passphrases/#platform-windows

Killing the agent before stick removal

Usually, before you remove your usbstick you ask Windows to eject the stick, by right clicking it in the explorer or using the little systray icon. This will not work, if your agent is still up and running. Make sure to kill the agent before closing the last shell upon stick removal:

$ ssh-agent -k

unset SSH_AUTH_SOCK;
unset SSH_AGENT_PID;
echo Agent pid 8472 killed;

Remark: Usually you would use eval $(ssh-agent -k) to unset the env vars as well, but as you do this just before closing the shell it's irrelevant. The above startup script .mgssh takes care of cleaning up the ~/.ssh/agent.env file so that does not have to be done either.