Git gui won't open existing repository if there is a disconnected network drive present

[robert.sim...@gmail.com]

I have a repository on my windows 7 laptop. It's been working fine for several months. Yesterday I tried to open up git-gui to commit some changes. The first thing I noticed was that the repository wasn't listed under 'Open Recent Repository'. I tried to open it manually and it complained that it couldn't find the .gitconfig file under U:. It turned out that I had been using U: to map a network drive but I wasn't connected to the network. This was all completely unrelated to anything I was doing with git. Unfortunately windows 7 has a known issue with mapping network drives which means that they can get into a state where you can't connect them and you can't delete them. I eventually managed to solve the problem by removing the drive from the registry and then turning on the offline mode (plus several reboots). The network drive is still there but now has a local copy of the files which seems to keep git happy. The question is though: why is git even looking at this drive? It has absolutely nothing to do with the repository which is on a different drive.

git-gui version 0.17.GITGUI
git version 1.8.3.msysgit.0

Tcl/Tk version 8.5.13

Rob.

[Pat Thoyts]

The list of recent repos is stored in your per-user git config
(~/.gitconfig). This is read and we call _is_git on each one which
checks for some files or subfolders existing in the directories
listed. You could delete those that are causing the problem and
git-gui would no longer try reading from the non-existent drive.

I suspect you could have cleaned up your system more simply using the
'net use' command from a cmd prompt. While Explorer may get stuck with
bad network mounts, you can get a listing using 'net use' and then
delete bad ones with 'net use X: /delete' or 'net use \\SHARE\Name
/delete'. Quite probably easier than messing in the registry and
rebooting N times.

If you had started the git-gui in the correct repository folder (the
explorer context-menu can offer this or you can use a command prompt,
change to the repository directory then issue "git gui") then you
would not have been offered a list of repos to choose from and it
would just have opened the current repository - also avoiding your
startup problem.

[robert.sim...@gmail.com]

Thanks for your reply. But...

The repo isn't listed in .gitconfig. At least the one in C:\Users\<user name>\.gitconfig, assuming I have the right location. The error said it was looking for that file in U:\.gitconfig.

I did try 'net use U: /delete' but it didn't work. IIRC, it couldn't find the drive or it was invalid. 'net use' by itself listed the drive ok. This is a very common problem in windows. Check the forums if you don't believe me.

The explorer context menu seems not to be present. I chose the 'advanced' context menu during intall. I confess I didn't try to start git-gui from the command prompt.


I've just triggered the problem again by deleting the network drive mapping. Here's what I get when I try to open the repository:

error: could not lock config file U:\/.gitconfig: No such file or directory
error: could not lock config file U:\/.gitconfig: No such file or directory
    while executing
"exec {C:/Program Files (x86)/Git/libexec/git-core/git-config.exe} --global --add gui.recentrepo C:/<path to repo>"
    ("eval" body line 1)
    invoked from within
"eval exec $opt $cmdp $args"
    (procedure "git" line 23)
    invoked from within
"git config --global --add gui.recentrepo $path"
    (procedure "_append_recentrepos" line 16)
    invoked from within
"_append_recentrepos [pwd]"
    (procedure "choose_repository::_do_open2" line 12)
    invoked from within
"choose_repository::_do_open2 ::choose_repository::__o1::__d"
    invoked from within
".buttons.next invoke "
    invoked from within
".buttons.next instate !disabled { .buttons.next invoke } "
    invoked from within
".buttons.next instate pressed { .buttons.next state !pressed; .buttons.next instate !disabled { .buttons.next invoke } } "
    (command bound to event)


.gitconfig:

[gui]
[gui]
  recentrepo = C:/Users/<path to repo>
  recentrepo = C:/Users/<path to repo>
[user]
  email = <email>
  name = <name>

If I try to start git-gui from the command line in the top level directory of the repository I get some strange errors if I don't have U: mapped:

couldn't open ".git/HEAD": no such file or directory
couldn't open ".git/HEAD": no such file or directory
    while executing
"open [gitdir HEAD] r"
    (procedure "load_current_branch" line 4)
    invoked from within
"load_current_branch"
    (procedure "repository_state" line 7)
    invoked from within
"repository_state newType newHEAD newMERGE_HEAD"
    (procedure "rescan" line 9)
    invoked from within
"rescan ui_ready"
    (procedure "do_rescan" line 2)
    invoked from within
"do_rescan"
    ("after" script)

If I map U: to an empty shared local directory, everything works fine.

[Edwin Castro]

On 8/25/13 7:13 AM, robert.sim...@gmail.com wrote:

The repo isn't listed in .gitconfig. At least the one in C:\Users\<user name>\.gitconfig, assuming I have the right location. The error said it was looking for that file in U:\.gitconfig.

http://git-scm.com/book/ch1-5.html says:

On Windows systems, Git looks for the .gitconfig file in the $HOME directory (%USERPROFILE% in Windows’ environment), which is C:\Documents and Settings\$USER or C:\Users\$USER for most people, depending on version ($USER is %USERNAME% in Windows’ environment). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer.


I think something is setting your HOME environment variable to U:\ for you. I vaguely remember a domain policy or something setting it for me when connected to the domain at work. When I worked at home disconnected from the domain I _think_ HOME resolved to %USERPROFILE% at C:\Users\<user name>\ as expected.

--
Edwin G. Castro

[Pat Thoyts]

On 25 August 2013 15:13, <robert.sim...@gmail.com> wrote:
> Thanks for your reply. But...
>
> The repo isn't listed in .gitconfig. At least the one in C:\Users\<user
> name>\.gitconfig, assuming I have the right location. The error said it was
> looking for that file in U:\.gitconfig.

In this case you have got HOME or USERPROFILE set to point to U:\. The
global .gitconfig file is going to be read every time you run a git
command and if HOME has been set to U:\ it will try to read this file
and others from this non-existent directory path.

>
> The explorer context menu seems not to be present. I chose the 'advanced'
> context menu during intall. I confess I didn't try to start git-gui from the
> command prompt.

Given you now mention that it is looking for .gitconfig - it won't
matter where you start git gui from. All instances of git commands are
going to suffer.

> I've just triggered the problem again by deleting the network drive mapping.
> Here's what I get when I try to open the repository:
>
> error: could not lock config file U:\/.gitconfig: No such file or directory

Setting HOME explictly will avoid the issue by overriding the
directory in which we will search for the global git configuration
files (.gitconfig, .gitignore and .gitattributes I think). This is
normally configured from %USERPROFILE% or %HOMEDRIVE%%HOMEPATH% in Git
for Windows but if HOME has been set then this is used instead.

Note that all git commands -- not just git-gui will try reading the
$HOME/.gitconfig file.

[robert.s...@gmail.com]

The only environment variable that points to U: is HOMEDRIVE. Unfortunately there's no way I can delete it as it is reset whenever I connect to the network.

Could I make a suggestion? It's obvious that git is quite happy if there is no .gitconfig present in the HOMEDRIVE directory. So could the behavior be changed so that it simply ignores the HOMEDRIVE (and HOME) if it points to an invalid drive?

Thanks,

Rob.

[robert.s...@gmail.com]

Please ignore the previous post, I misunderstood the earlier comments.

Setting HOME to C:\Users\<username> cures the problem. Thanks!