git, branch v1.5.4-rc4

GIT 1.5.4-rc4

2008-01-21T01:05:11Z

Signed-off-by: Junio C Hamano

Merge git://repo.or.cz/git-gui

2008-01-21T00:58:38Z

* git://repo.or.cz/git-gui: git-gui: Makefile - Handle $DESTDIR on Cygwin git-gui: add french glossary: glossary/fr.po git-gui: Refresh file status description after hunk application git-gui: Allow 'Create New Repository' on existing directories git-gui: Initial french translation git-gui: Improve German translation. git-gui: Updated Swedish translation after mailing list review. git-gui: Fix broken revert confirmation. git-gui: Update German translation git-gui: Update glossary: add term "hunk"

Merge git://git.kernel.org/pub/scm/gitk/gitk

2008-01-21T00:57:56Z

* git://git.kernel.org/pub/scm/gitk/gitk: [PATCH] gitk: make Ctrl "+" really increase the font size

http-push and http-fetch: handle URLs without trailing /

2008-01-20T23:18:34Z

The URL to a repository http-push and http-fetch takes should have a trailing slash. Instead of failing the request, add it ourselves before attempting such a request. Signed-off-by: Junio C Hamano

http-push: clarify the reason of error from the initial PROPFIND request

2008-01-20T23:17:58Z

The first thing http-push does is a PROPFIND to see if the other end supports locking. The failure message we give is always reported as "no DAV locking support at the remote repository", regardless of the reason why we ended up not finding the locking support on the other end. This moves the code to report "no DAV locking support" down the codepath so that the message is issued only when we successfully get a response to PROPFIND and the other end say it does not support locking. Other failures, such as connectivity glitches and credential mismatches, have their own error message issued and we will not issue "no DAV locking" error (we do not even know if the remote end supports it). Signed-off-by: Junio C Hamano

http-push: fail when info/refs exists and is already locked

2008-01-20T23:17:58Z

Failing instead of silently not updating remote refs makes the things clearer for the user when trying to push on a repository while another person do (or while a dandling locks are waiting for a 10 minutes timeout). When silently not updating remote refs, the user does not even know that git has pushed the objects but leaved the refs as they were before (e.g. a new bunch of commits on branch "master" is uploaded, however the branch by itsel still points on the previous head commit). Signed-off-by: Junio C Hamano

http-push: fix webdav lock leak.

2008-01-20T23:17:58Z

Releasing webdav lock even if push fails because of bad (or no) reference on command line. To reproduce the issue that this patch fixes, prepare a test repository availlable over http+webdav, say at http://myhost/myrepo.git/ Then: $ git clone http://myhost/myrepo.git/ $ cd myrepo $ git push http Fetching remote heads... refs/ refs/heads/ refs/tags/ No refs in common and none specified; doing nothing. $ git push http Fetching remote heads... refs/ refs/heads/ refs/tags/ No refs in common and none specified; doing nothing. $ Finally, you look at the web server logs, and will find one LOCK query and no UNLOCK query, of course the second one will be in 423 return code instead of 200: 1.2.3.4 - gb [19/Jan/2008:14:24:56 +0100] "LOCK /myrepo.git/info/refs HTTP/1.1" 200 465 (...) 1.2.3.4 - gb [19/Jan/2008:14:25:10 +0100] "LOCK /myrepo.git/info/refs HTTP/1.1" 423 363 With this patch, there would have be two UNLOCKs in addition of the LOCKs From the user's point of view: - If you realize that you should have typed e.g. "git push http master" instead of "git push http", you will have to wait for 10 minutes for the lock to expire by its own. - Furthermore, if somebody else is dumb enough to type "git push http" while you need to push "master" branch, then you'll need too to wait for 10 minutes too. Signed-off-by: Gr.ANigoire Barbier Signed-off-by: Junio C Hamano

parse_commit_buffer: tighten checks while parsing

2008-01-20T19:00:57Z

This tightens the parsing of a commit object in a couple of ways. - The "tree " header must end with a LF (earlier we did not check this condition). - Make sure parsing of timestamp on the "committer " header does not go beyond the buffer, even when (1) the "author " header does not end with a LF (this means that the commit object is malformed and lacks the committer information) or (2) the "committer " header does not have ">" that is the end of the e-mail address, or (3) the "committer " header does not end with a LF. We however still keep the existing behaviour to return a parsed commit object even when non-structural headers such as committer and author are malformed, so that tools that need to look at commits to clean up a history with such broken commits can still get at the structural data (i.e. the parents chain and the tree object). Signed-off-by: Martin Koegler Signed-off-by: Junio C Hamano

Update git-completion for new 'remote rm' option

2008-01-20T07:06:02Z

Signed-off-by: Dan McGee Signed-off-by: Junio C Hamano

doc typo: s/prior committing/prior to committing/

2008-01-19T19:25:37Z

Signed-off-by: Jim Meyering Signed-off-by: Junio C Hamano