user/sven/git.git, branch v1.6.5.4

Git 1.6.5.4

2009-12-03T08:08:16Z

Signed-off-by: Junio C Hamano

Unconditionally set man.base.url.for.relative.links

2009-12-03T08:06:52Z

Even setting it to empty is better than leaving it unset as it prevents the warning cruft from appearing in the output. Signed-off-by: Junio C Hamano

Documentation/Makefile: allow man.base.url.for.relative.link to be set from Make

2009-12-03T02:45:09Z

Signed-off-by: Junio C Hamano

Prepare for 1.6.5.4

2009-12-02T18:29:00Z

Signed-off-by: Junio C Hamano

merge: do not add standard message when message is given with -m option

2009-12-02T18:02:08Z

Even if the user explicitly gave her own message to "git merge", the command still added its standard merge message. It resulted in a useless repetition like this: % git merge -m "Merge early part of side branch" `git rev-parse side~2` % git show -s commit 37217141e7519629353738d5e4e677a15096206f Merge: e68e646 a1d2374 Author: しらいしななこ Date: Wed Dec 2 14:33:20 2009 +0900 Merge early part of side branch Merge commit 'a1d2374f8f52f4e8a53171601a920b538a6cec23' The gave her own message because she didn't want git to add the standard message (if she wanted to, she wouldn't have given one, or she would have prepared it using git-fmt-merge-msg command). Noticed by Nanako Shiraishi Signed-off-by: Junio C Hamano

Do not misidentify "git merge foo HEAD" as an old-style invocation

2009-12-02T18:01:59Z

This was misinterpreted as an ancient style "git merge HEAD ..." that merges one (or more) into the current branch and record the resulting commit with the given message. Then a later sanity check found that there is no specified and gave a usage message. Tested-by: Nanako Shiraishi Signed-off-by: Junio C Hamano

help: Do not unnecessarily look for a repository

2009-12-01T20:10:09Z

Although 'git help' actually doesn't need to be run inside a git repository and uses no repository-specific information, it looks for a git directory. Searching for a git directory can be annoying in auto-mount environments. With this commit, 'git help' no longer searches for a repository when run without any options. 7c3baa9 originally modified 'git help -a' to not require a repository. This applies the same fix for 'git help'. Signed-off-by: David Aguilar Signed-off-by: Junio C Hamano

Documentation: Fix a few i.e./e.g. mix-ups

2009-12-01T20:09:46Z

A git bundle can be transported by several means (such as e-mail), not only by snekaernet, so use e.g. instead of i.e. The mix-up in git-bundle.txt is obvious. Signed-off-by: Michael J Gruber Signed-off-by: Junio C Hamano

Documentation: Document --branch option in git clone synopsis

2009-11-30T16:47:54Z

Document the --branch option as [-b ] in git clones synopsis. Signed-off-by: David Soria Parra Signed-off-by: Junio C Hamano

builtin-apply.c: pay attention to -p when determining the name

2009-11-27T03:02:24Z

The patch structure has def_name component that is used to validate the sanity of a "diff --git" patch by checking pathnames that appear on the patch header lines for consistency. The git_header_name() function is used to compute this out of "diff --git a/... b/..." line, but the code always stripped one level of prefix (i.e. "a/" and "b/"), without paying attention to -p option. Code in find_name() function that parses other lines in the patch header (e.g. "--- a/..." and "+++ b/..." lines) however did strip the correct number of leading paths prefixes, and the sanity check between these computed values failed. Teach git_header_name() to honor -p option like find_name() function does. Found and reported by Steven J. Murdoch who also wrote tests. Signed-off-by: Junio C Hamano