First check HOME setting, then change HOME and HOMEDRIVE to a existing dir.
c:\git>set HOME
HOME=U:\
HOMEDRIVE=U:
HOMEPATH=\
then change HOME and HOMEDRIVE by
set HOME=c:\tmp
set HOMEDRIVE=C:
I have solved this problem using a slightly different approach that I have seen work for other configuration files. Git Config supports includes that allows you to point to a configuration file in another location. That alternate location is then imported and expanded in place as if it was part of .gitconfig file. So now I just have a single entry in .gitconfig:
[include]
path = c:\\path\\to\\my.config
Any updates written by Git to the .gitconfig file will not overwrite my include path. It does mean that occasionally I may need to move values from .gitconfig to my.config.
For me it worked very simple:
Change HOME directory for this is wrong. Better is create symbolic link for gitconfig to HOME directory.
Look in the FILES and ENVIRONMENT section of git help config
.
If you are on windows and having problem either changing environment variables or mklink
because of insufficient privileges, an easy solution to your problem is to start git batch in another location.
Just right click on Git Bash.exe, click properties and change the "Start in" property to c:\my_configuration_files\
.
Solution without having to change Windows HOME variable
OS: Windows 10
git version: 2.27.0.windows.1
I use portable version of Git, so all my config files are on my pen-drive(E:). This is what worked for me:
.gitconfig
and other bash files in E, so I created a folder called home where I want them all in.mkdir home
HOME="E:\git\home"
Now it no longer searches in the C:\Users<username> directory for .gitconfig but only looks in your set path above.
$ git config --global --list
fatal: unable to read config file 'E:/git/home/.gitconfig': No such file or directory
It gave an error because there isn't a .gitconfig file there yet. This is just to demonstrate that we have successfully changed the location of the .gitconfig file without changing the HOME directory in Windows.
%PROGRAMFILES%\Git\etc
profile
HOME="c:\location_were_you_want_gitconfig"
Note: The file permissions are usually restricted, so change them accordingly or you won't be able to save your changes.
I wanted to do the same thing. The best I could find was @MicTech's solution. However, as pointed out by @MotoWilliams this does not survive any updates made by Git to the .gitconfig file which replaces the link with a new file containing only the new settings.
I solved this by writing the following PowerShell script and running it in my profile startup script. Each time it is run it copies any settings that have been added to the user's .gitconfig to the global one and then replaces all the text in the .gitconfig file with and [include] header that imports the global file.
I keep the global .gitconfig file in a repo along with a lot of other global scripts and tools. All I have to do is remember to check in any changes that the script appends to my global file.
This seems to work pretty transparently for me. Hope it helps!
Sept 9th: Updated to detect when new entries added to the config file are duplicates and ignore them. This is useful for tools like SourceTree which will write new updates if they cannot find existing ones and do not follow includes.
function git-config-update
{
$localPath = "$env:USERPROFILE\.gitconfig".replace('\', "\\")
$globalPath = "C:\src\github\Global\Git\gitconfig".replace('\', "\\")
$redirectAutoText = "# Generated file. Do not edit!`n[include]`n path = $globalPath`n`n"
$localText = get-content $localPath
$diffs = (compare-object -ref $redirectAutoText.split("`n") -diff ($localText) |
measure-object).count
if ($diffs -eq 0)
{
write-output ".gitconfig unchanged."
return
}
$skipLines = 0
$diffs = (compare-object -ref ($redirectAutoText.split("`n") |
select -f 3) -diff ($localText | select -f 3) | measure-object).count
if ($diffs -eq 0)
{
$skipLines = 4
write-warning "New settings appended to $localPath...`n "
}
else
{
write-warning "New settings found in $localPath...`n "
}
$localLines = (get-content $localPath | select -Skip $skipLines) -join "`n"
$newSettings = $localLines.Split(@("["), [StringSplitOptions]::RemoveEmptyEntries) |
where { ![String]::IsNullOrWhiteSpace($_) } | %{ "[$_".TrimEnd() }
$globalLines = (get-content $globalPath) -join "`n"
$globalSettings = $globalLines.Split(@("["), [StringSplitOptions]::RemoveEmptyEntries)|
where { ![String]::IsNullOrWhiteSpace($_) } | %{ "[$_".TrimEnd() }
$appendSettings = ($newSettings | %{ $_.Trim() } |
where { !($globalSettings -contains $_.Trim()) })
if ([string]::IsNullOrWhitespace($appendSettings))
{
write-output "No new settings found."
}
else
{
echo $appendSettings
add-content $globalPath ("`n# Additional settings added from $env:COMPUTERNAME on " + (Get-Date -displayhint date) + "`n" + $appendSettings)
}
set-content $localPath $redirectAutoText -force
}
I'm no Git master, but from searching around the solution that worked easiest for me was to just go to C:\Program Files (x86)\Git\etc
and open profile
in a text editor.
There's an if
statement on line 37 # Set up USER's home directory
. I took out the if
statement and put in the local directory that I wanted the gitconfig to be, then I just copied my existing gitconfig file (was on a network drive) to that location.
As someone who has been interested in this for a VERY LONG TIME. See from the manual:
$XDG_CONFIG_HOME/git/config - Second user-specific configuration file. If $XDG_CONFIG_HOME
is not set or empty, $HOME/.config/git/config will be used. Any single-valued variable set in this file will be overwritten by whatever is in ~/.gitconfig. It is a good idea not to create this file if you sometimes use older versions of Git, as support for this file was added fairly recently.
Which was only recently added. This dump is from 2.15.0.
Works for me.
For me, changing the Start In location (of git-gui at least) did not affect where it looked for .gitconfig. My setup at work mounts U: for our home, but we do not have permission to write in U: directly, only subdirectories which were created for us inside, so this was a deal-breaker for me.
I solved the problem by making a batch script which would override the HOMEDRIVE and HOMEPATH env variables just for that application. Then changed my Start menu shortcut to point to that batch script instead.
Source: Stackoverflow.com