Improve HOMEDRIVE/HOMEPATH configuration.

[kwah-gh]

Setup

Git-2.8.3-64-bit.exe

$git version
git version 2.8.3.windows.1

64-bit Windows 7 SP1

Defaults used upon setup (only destination folder is different).

Environment settings on our company PCs are such that %HOMEDRIVE%%HOMEPATH% points to shared Linux user home.

Details

After setting up newer version of Git for Windows (previously used Git-1.9.5-preview20150319.exe) see the following:

Upon start of Git Bash it looks like it does not process correctly Git for Win configuration files.

I recon it discovers profile/bash config files in %HOMEDRIVE%%HOMEPATH% (in a shared Linux home as mentioned in the previous section) and proper bash configuration on local system is never picked up. This results in all convenience features gone:

• No colors in terminal
• No command helpers
• No branch in command line prompt
• ...

Workaround

In Git4Win setup destination /etc/profile we add (just before # Define default printer" line):

# Fix [start]: do not use $HOMEDRIVE$HOMEPATH as HOME
if [ -z "$USERNAME" ]; then
  LOGNAME="`id -un`"
else
  LOGNAME="$USERNAME"
fi
HOME="/home/$LOGNAME"
# Fix [end]

We had to use similar workaround in Git-1.9.5-preview20150319

Question

Is it possible to have structural out of the box solution, which will take into account aforementioned use case? Namely, detect HOMEDRIVE + HOMEPATH pointing to location with profile/shell configuration files out of Git4Win setup tree and make use of Git4Win configuration instead?

[dscho]

If I understand correctly, you simply want to edit your /etc/nsswitch.conf file and modify the db_home line to read db_home: /home/%u.

However, please note that you do seem to have quite a non-standard setup. The standard setup will always use HOME (falling back to HOMEDRIVE``HOMEPATHand thenUSERPROFILE) as home directory.

[kwah-gh]

Since I do not have much experience with it, I do not know what would be the best way to configure the PC, where HOMEDRIVE and HOMEPATH are set (while the HOME is not).

If I understood your remark correctly, setting up HOME environment variable pointing to wherever "user home" with proper configuration files is, should be enough.

Still wondering though, whether it is intended behavior that a clean install of Git for Windows does not configure the HOME and ends-up in a HOMEDRIVE + HOMEPATH fall-back scenario.

[dscho]

@kwah-gh a clean install cannot configure HOME because that would be valid only for the installing user.

Of course, this assumes that we want to use Windows' idea of the home directory. You want something different, apparently, but please note that you are in the vast minority with that desire. Judging from this here bug tracker, most users agree with the choice of HOMEDRIVE\HOMEPATH as home directory.

[kwah-gh]

Sorry, but I do not understand. I do agree with a choice of HOMEDRIVE\HOMEPATH as home directory.

The issue at hand is: if HOMEDRIVE\HOMEPATH has shell/profile configuration files, these are being picked up by Git Bash. If these configuration files depend on other generic configuration files that are sourced from locations mounted when user logs in to his Linux account (like in our particular case), they cannot be properly sourced (and thus correctly processed) by Git 4 Windows tools that are using HOMEDRIVE\HOMEPATH as a home directory.

We probably could introduce some internal logic in the configuration files exposed in HOEMDRIVE\HOMEPATH to detect that they are used from windows client, and make decisions based on some environment variables set, like MSYSTEM. But then we need to introduce separate configuration files for git on windows and Linux (e.g. due to eol-handling) and maybe other files as well. Therefore the original question/request for advice.

Current workaround being used (with setting specific HOME) avoids discovery of user Linux account configuration files and keeps things separate between Git Bash in Windows environment and Linux environment.

[dscho]

if HOMEDRIVE\HOMEPATH has shell/profile configuration files, these are being picked up by Git Bash.

Yes. In my Windows setup, I do have a $HOME/.bashrc and I want it to be picked up.

So the feature works as designed.

If these configuration files depend on other generic configuration files that are sourced from locations mounted when user logs in to his Linux account (like in our particular case), they cannot be properly sourced (and thus correctly processed) by Git 4 Windows tools that are using HOMEDRIVE\HOMEPATH as a home directory.

Yes. And in this case, your $HOME/.bashrc is the problem. If you wish to have a certain directory as home directory, and said directory contains a .bashrc file, then it is logical to assume that you want Bash to interpret it. Hence it is your responsibility to ensure that the contained instructions work wherever you want this as home directory.

We probably could introduce some internal logic in the configuration files exposed in HOEMDRIVE\HOMEPATH to detect that they are used from windows client, and make decisions based on some environment variables set

If you want to reuse the same directory as home directory in multiple setups, yes, you have to ensure that your .bashrc is valid in all of those cases, or not call Bash, ever.

I did have such a system myself, a long, long time ago. In my case it turned out that the OS was not so much the problem as the very different file system layouts, and I needed different handling for CentOS and for Ubuntu. I solved the issue by replacing the case "$(uname -s)" solution with a case "$HOSTNAME" one. Maybe that would help in your case, too.

In short: I really have to stress that this is the opposite of a bug. The system works exactly as designed, it just so happens that you did not design your .bashrc to account for it.