The git config -fcommand doesn't work with a file of network folder for me.

[ghost]

Git for Windows 2.4.5 x64.
It works fine with a local config-file:
git config -f "d:\\dev\\settings\\gitconfig.txt" http.proxy http://@proxy2:8080

I need to do the same with a config-file which is located at the network in our domain. This config-file is common for all developers of our company and has common settings (the proxy settings, for example). I have full rights for working with that directory. This is my directory only. It was created special for me by admin (an hour ago) and only I have full access to it.

I launch this:
git config -f "\\\\hyprostr\\dfs\\groups\\developers\\settings\\gitconfig.txt" http.proxy http://@proxy2:8080

But it doesn't work. I see the message:

if I press y then I get the same message again... I reloaded my computer, but it didn't help.

Through Windows Explorer I create, edit, remove and rename files and directories without problems in this location.

Why does it happen and how can I fix it?

This works fine (from Git Bash): :
echo 123 > "\\\\hyprostr\\dfs\\groups\\developers\\settings\\gitconfig.txt"

and this works fine too:
mv "\\\\hyprostr\\dfs\\groups\\developers\\settings\\gitconfig.txt" "\\\\hyprostr\\dfs\\groups\\developers\\settings\\gitconfig2.txt"

So, I don't understand the reason of the problem... :(((

[ghost]

I see the gitconfig.txt.lock at the same directory. It was created by Git but not removed (I don't know why). I removed it manually and now it works fine.

[kostix]

Windows has no problems interpreting / instead of \ which could make your life significantly easier:

kostix@programmer MINGW32 ~
$ git config --file //tigra/kostix/foo.conf --list
core.whatever=bar

kostix@programmer MINGW32 ~
$ cat //tigra/kostix/foo.conf
[core]
whatever = bar

kostix@programmer MINGW32 ~
$

I think the same applies to #239.

[ghost]

Oh.... Problem is not solved. It works for the first attempting only. I will write video. I am thinking this is a bug.

[ghost]

Look this video about the problem: http://www.youtube.com/watch?v=kudZ8jTg7Ww&feature=youtu.be

[ghost]

Is it a bug?

[dscho]

@Andrey-Bushman have you looked in detail at @kostix's answer? I believe that his advice essentially resolves this ticket.

[ghost]

No, using / instead of \\ doesn't help. Pay attention: the problem is not with reading:
git config -f "//hyprostr/dfs/groups/developers/settings/gitconfig.txt" --list
it works fine. But problem with writting:
git config -f "//hyprostr/dfs/groups/developers/settings/gitconfig.txt" http.proxy http://@proxy2:8080
Did you see my video of the problem?

[kostix]

I did not watch the video (Andrey, posting a video is rather pointless in most cases as it requires context switching, and it's not googleable), but writing to a config file on a share does not work for me either:

kostix@programmer MINGW32 ~
$ git config -f //tigra/kostix/foo.conf --list
core.whatever=bar

kostix@programmer MINGW32 ~
$ git config -f //tigra/kostix/foo.conf mumbo.jumbo xyzzy
error: could not commit config file //tigra/kostix/foo.conf

kostix@programmer MINGW32 ~
$ git config -f //tigra/kostix/foo.conf --add mumbo.jumbo xyzzy
error: could not commit config file //tigra/kostix/foo.conf

I did not see the code (yet) but I have a vague feeling that Git, which had been engeneered by professionals, does not attempt to blindly overwrite the file with the new content, but rather creates another one in the same directory, fsync()s the write then calls rename(new_name, orig_name) (and then possibly fsync()s the directory entry).

May be this atomic rename is broken in GfW because it does not use ReplaceFile (which should work for UNC paths) or calls it with the lpBackupFileName set to NULL which appears to make a big difference in certain cases.

In either case all this are just my wild guesses, unfortunately.

[ghost]

It can be used as workaround of the bug:
mv "//hyprostr/dfs/groups/developers/settings/gitconfig.txt" "./gitconfig.txt"
git config -f "./gitconfig.txt" http.proxy http://@proxy2:8080
mv "./gitconfig.txt" "//hyprostr/dfs/groups/developers/settings/gitconfig.txt"
It is not a nice decission, but it works for me.

[drizzd]

This seems to be the code in question:
https://github.com/git-for-windows/git/blob/master/lockfile.c#L290

We call fclose immediately followed by MoveFileExW. Maybe this is too fast for Windows shares?
https://github.com/git-for-windows/git/blob/master/lockfile.c#L265
https://github.com/git-for-windows/git/blob/master/compat/mingw.c#L1862

[ghost]

Maybe this is too fast for Windows shares?

I don't know, I am not expert in C and OS Windows. To get the expected result is important for me. My previous message does it.

I read the git help config about the alias.*. After reading I am thinking what it is not possible to write these three commands through an alias. Am I right? I hope I am mistaken, still and it is possible. If I am mistaken, then how can I do it?

[ghost]

I solved my problem with alias here: http://stackoverflow.com/questions/31447193/can-i-use-a-set-of-commands-external-and-internal-for-a-git-alias
Also I described it here: http://www.git-for-win.red-bee.ru/index.html?git_important_settings.html

[dscho]

@Andrey-Bushman couldn't you just have pasted the relevant parts in this ticket, to make things easier for everybody else?

[ghost]

couldn't you just have pasted the relevant parts in this ticket, to make things easier for everybody else?

Ok. I wrote such script:

# edit_config.sh
# © Andrey Bushman, 2015
# This is a workaround of the problem described here:
# https://github.com/git-for-windows/git/issues/241
# Arguments:
# $1 - target config file
# $2 - parameter full name
# $3 - parameter value
random_file_name=$RANDOM
mv $1 $random_file_name
git config -f $random_file_name $2 $3
mv $random_file_name $1

The script file I located in the network also. Now it can be launched either through Git Bash directly:

sh "//hyprostr/dfs/groups/developers/settings/edit_config.sh" "//hyprostr/dfs/groups/developers/settings/gitconfig.txt" "http.proxy" "http://@proxy2:8080"

or through the alias

git config --global alias.editconfig '!sh "//hyprostr/dfs/groups/developers/settings/edit_config.sh"'

I can launch this:

git editconfig "//hyprostr/dfs/groups/developers/settings/gitconfig.txt" "http.proxy" "http://@proxy2:8080"

It works fine for me.

[drizzd]

I cannot reproduce. Works perfectly for me. :-(

[ghost]

Did you see my video? I showed, what sometimes it works for me. The keyword is sometimes... Both variants of behaviour are present on the video.

[dscho]

@Andrey-Bushman A video is probably not the most appropriate way to relate your problem. And if it works sometimes you might want to try to figure out what are the circumstances when it works vs when it does not, and report back the findings.

[ghost]

A video is probably not the most appropriate way to relate your problem. And if it works sometimes you might want to try to figure out what are the circumstances when it works vs when it does not, and report back the findings.

@dscho, I didn't reveal regularity of this behavior. Also, I haven't time for this spending, sorry. :( Video shows a problem for people, whom this problem isn't reproduced. It shows both variants of working (successed\failed). Also I showed a workaround.

So, I found a problem; I reported about it; I even recorded video for who doesn't have this problem; I showed a workaround (but it is not a fix of the bug). What more? I won't persuade developers to correct it. If on your computer the problem isn't reproduced and therefore you consider that it doesn't exist, then let will be such final of the "bug" (or not the "bug" if you want this variant). I don't force you to watch this video. It can be interesting to developers which will want to fix this problem.

I think that there is no sense continue to discuss of this topic, therefore I close it.

I cannot reproduce. Works perfectly for me. :-(

It successfully worked for me few times only. The same problem I got for other computers also.

P.S. If the video is interesting for nobody then I can delete it.

[ghost]

The problem fixed in the Git for Windows v.2.5.2.