I had some troubles using Git via HTTP/WebDAV, because it seems like Git does not correctly support HTTP authentication. Fortunately, it turned out that using a .netrc-file solves the problems.

The symptoms were the following: After successfully installing Redmine and Git using some nice instructions I found on a blog, I had permanent problems using the git push command:

$ git push
Username: 
Password: 
Fetching remote heads...
  refs/
  refs/heads/
  refs/tags/
updating 'refs/heads/master'
  from a698d7bfbd2147cc8ba850aefab63f9591e1e395
  to   fa8dd4f3454c72525061d4a94c93ee547f682f69
    sending 3 objects
MKCOL 148cad6c4de87c7cca4265293b238e9b738cd398 failed, aborting (22/401)
MKCOL fa8dd4f3454c72525061d4a94c93ee547f682f69 failed, aborting (22/401)
Updating remote server info
fatal: git-http-push failed

The strange thing was, that I always had to execute git push exactly three times, then it worked. After examination of the HTTP output produced with the command GIT_CURL_VERBOSE=1 git push, I noticed that Git sends the HTTP authentication stuff only for the first MKCOL WebDav command, not for the follwing two. Therefore it was necessary to execute the command three times. However, the solution to the problem was to create a .netrc-file in the $HOME-directory and provide it with the needed login:

machine <servername>
login <username>
password <password>

Now the authentication information gets always passed to the server and therefore the MKCOL commands are successfully executed.

Update: Another problem I just encountered was when uploading large files, it might occur that the DAV lock timeout mechanism might cause another “git-http-push failed” error:

git-http-push failed 412 unable to refresh lock

The solution is to increase the timeout in your Apache configuration:

# set minimum timeout to 1h:
DavMinTimeout 3600

Update 2 (thanks to cschmidt): For reference (and to make it easier to find this article through search engines): the corresponding errors in the server log:

The precondition(s) specified by the "If:" header did not match this resource. At least one failure is because: a State-token was supplied, but it was not found in the locks on this resource. [412, #0]

The locktoken specified in the "Lock-Token:" header is invalid because this resource has no outstanding locks. [400, #0]