summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-11-20Further preparation for 1.8.0.1Libravatar Junio C Hamano1-1/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-20Merge branch 'mg/maint-pull-suggest-upstream-to' into maintLibravatar Junio C Hamano1-1/+1
* mg/maint-pull-suggest-upstream-to: push/pull: adjust missing upstream help text to changed interface
2012-11-20Merge branch 'mm/maint-doc-commit-edit' into maintLibravatar Junio C Hamano1-0/+5
* mm/maint-doc-commit-edit: Document 'git commit --no-edit' explicitly
2012-11-20Merge branch 'as/maint-doc-fix-no-post-rewrite' into maintLibravatar Junio C Hamano1-4/+3
* as/maint-doc-fix-no-post-rewrite: commit: fixup misplacement of --no-post-rewrite description
2012-11-20Merge branch 'rs/lock-correct-ref-during-delete' into maintLibravatar Junio C Hamano1-13/+5
* rs/lock-correct-ref-during-delete: refs: lock symref that is to be deleted, not its target
2012-11-20Merge branch 'rf/maint-mailmap-off-by-one' into maintLibravatar Junio C Hamano1-1/+1
* rf/maint-mailmap-off-by-one: mailmap: avoid out-of-bounds memory access
2012-11-20Merge branch 'jk/maint-diff-grep-textconv' into maintLibravatar Junio C Hamano2-2/+14
"git diff -G<pattern>" did not honor textconv filter when looking for changes. * jk/maint-diff-grep-textconv: diff_grep: use textconv buffers for add/deleted files
2012-11-20Merge branch 'js/format-2047' into maintLibravatar Junio C Hamano5-126/+262
Various rfc2047 quoting issues around a non-ASCII name on the From: line in the output from format-patch have been corrected. * js/format-2047: format-patch tests: check quoting/encoding in To: and Cc: headers format-patch: fix rfc2047 address encoding with respect to rfc822 specials format-patch: make rfc2047 encoding more strict format-patch: introduce helper function last_line_length() format-patch: do not wrap rfc2047 encoded headers too late format-patch: do not wrap non-rfc2047 headers too early utf8: fix off-by-one wrapping of text
2012-11-18Start preparing for 1.8.0.1Libravatar Junio C Hamano2-1/+47
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-18Merge branch 'sz/maint-curl-multi-timeout' into maintLibravatar Junio C Hamano1-0/+12
Sometimes curl_multi_timeout() function suggested a wrong timeout value when there is no file descriptors to wait on and the http transport ended up sleeping for minutes in select(2) system call. A workaround has been added for this. * sz/maint-curl-multi-timeout: Fix potential hang in https handshake
2012-11-18Merge branch 'po/maint-refs-replace-docs' into maintLibravatar Junio C Hamano1-0/+6
The refs/replace hierarchy was not mentioned in the repository-layout docs. * po/maint-refs-replace-docs: Doc repository-layout: Show refs/replace
2012-11-18Merge branch 'ph/pull-rebase-detached' into maintLibravatar Junio C Hamano1-0/+1
"git pull --rebase" run while the HEAD is detached tried to find the upstream branch of the detached HEAD (which by definition does not exist) and emitted unnecessary error messages. * ph/pull-rebase-detached: git-pull: Avoid merge-base on detached head
2012-11-18Merge branch 'mm/maint-doc-remote-tracking' into maintLibravatar Junio C Hamano4-6/+6
Update "remote tracking branch" in the documentation to "remote-tracking branch". * mm/maint-doc-remote-tracking: Documentation: remote tracking branch -> remote-tracking branch
2012-11-18Merge branch 'rs/branch-del-symref' into maintLibravatar Junio C Hamano2-26/+68
A symbolic ref refs/heads/SYM was not correctly removed with "git branch -d SYM"; the command removed the ref pointed by SYM instead. * rs/branch-del-symref: branch: show targets of deleted symrefs, not sha1s branch: skip commit checks when deleting symref branches branch: delete symref branch, not its target branch: factor out delete_branch_config() branch: factor out check_branch_commit()
2012-11-18Merge branch 'nd/grep-true-path' into maintLibravatar Junio C Hamano4-17/+51
"git grep -e pattern <tree>" asked the attribute system to read "<tree>:.gitattributes" file in the working tree, which was nonsense. * nd/grep-true-path: grep: stop looking at random places for .gitattributes
2012-11-18Merge branch 'jc/grep-pcre-loose-ends' (early part) into maintLibravatar Junio C Hamano5-128/+204
"git log -F -E --grep='<ere>'" failed to use the given <ere> pattern as extended regular expression, and instead looked for the string literally. * 'jc/grep-pcre-loose-ends' (early part): log --grep: use the same helper to set -E/-F options as "git grep" revisions: initialize revs->grep_filter using grep_init() grep: move pattern-type bits support to top-level grep.[ch] grep: move the configuration parsing logic to grep.[ch] builtin/grep.c: make configuration callback more reusable
2012-11-18Merge branch 'da/mergetools-p4' into maintLibravatar Junio C Hamano1-0/+25
"git mergetool" feeds /dev/null as a common ancestor when dealing with an add/add conflict, but p4merge backend cannot handle it. Work it around by passing a temporary empty file. * da/mergetools-p4: mergetools/p4merge: Handle "/dev/null"
2012-11-18Merge branch 'jc/test-say-color-avoid-echo-escape' into maintLibravatar Junio C Hamano1-1/+1
The "say" function in the test scaffolding incorrectly allowed "echo" to interpret "\a" as if it were a C-string asking for a BEL output. * jc/test-say-color-avoid-echo-escape: test-lib: Fix say_color () not to interpret \a\b\c in the message
2012-11-18Merge branch 'bw/config-lift-variable-name-length-limit' into maintLibravatar Junio C Hamano1-30/+29
The configuration parser had an unnecessary hardcoded limit on variable names that was not checked consistently. * bw/config-lift-variable-name-length-limit: Remove the hard coded length limit on variable names in config files
2012-11-08push/pull: adjust missing upstream help text to changed interfaceLibravatar Michael J Gruber1-1/+1
In case of a missing upstream, the git-parse-remote script suggests: If you wish to set tracking information for this branch you can do so with: git branch --set-upstream nsiv2 origin/<branch> But --set-upstream is deprectated. Change the suggestion to: git branch --set-upstream-to=origin/<branch> nsiv2 Reported-by: Jeroen van der Ham <vdham@uva.nl> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jeff King <peff@peff.net>
2012-11-02commit: fixup misplacement of --no-post-rewrite descriptionLibravatar Andreas Schwab1-4/+3
In e858af6 (commit: document a couple of options) the description of the --no-post-rewrite option was put inside the paragraph for the --amend option. Move it down after the paragraph. Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Jeff King <peff@peff.net>
2012-11-02Document 'git commit --no-edit' explicitlyLibravatar Matthieu Moy1-0/+5
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Jeff King <peff@peff.net>
2012-10-28diff_grep: use textconv buffers for add/deleted filesLibravatar Jeff King2-2/+14
If you use "-G" to grep a diff, we will apply a configured textconv filter to the data before generating the diff. However, if the diff is an addition or deletion, we do not bother running the diff at all, and just look for the token in the added (or removed) content. This works because we know that the diff must contain every line of content. However, while we used the textconv-derived buffers in the regular diff, we accidentally passed the original unmodified buffers to regexec when checking the added or removed content. This could lead to an incorrect answer. Worse, in some cases we might have a textconv buffer but no original buffer (e.g., if we pulled the textconv data from cache, or if we reused a working tree file when generating it). In that case, we could actually feed NULL to regexec and segfault. Reported-by: Peter Oberndorfer <kumbayo84@arcor.de> Signed-off-by: Jeff King <peff@peff.net>
2012-10-28mailmap: avoid out-of-bounds memory accessLibravatar Romain Francoise1-1/+1
AddressSanitizer (http://clang.llvm.org/docs/AddressSanitizer.html) complains of a one-byte buffer underflow in parse_name_and_email() while running the test suite. And indeed, if one of the lines in the mailmap begins with '<', we dereference the address just before the beginning of the buffer when looking for whitespace to remove, before checking that we aren't going too far. So reverse the order of the tests to make sure that we don't read outside the buffer. Signed-off-by: Romain Francoise <romain@orebokech.com> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25Doc repository-layout: Show refs/replaceLibravatar Philip Oakley1-0/+6
Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25Documentation: remote tracking branch -> remote-tracking branchLibravatar Matthieu Moy4-6/+6
This change was already done by 0e615b252f3 (Matthieu Moy, Tue Nov 2 2010, Replace "remote tracking" with "remote-tracking"), but new instances of remote tracking (without dash) were introduced in the meantime. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-pull: Avoid merge-base on detached headLibravatar Phil Hord1-0/+1
git pull --rebase does some clever tricks to find the base for $upstream, but it forgets that we may not have any branch at all. When this happens, git merge-base reports its "usage" help in the middle of an otherwise successful rebase operation, because git-merge is called with one too few parameters. Since we do not need the merge-base trick in the case of a detached HEAD, detect this condition and bypass the clever trick and the usage noise. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Jeff King <peff@peff.net>
2012-10-21Git 1.8.0Libravatar Junio C Hamano3-10/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-19Fix potential hang in https handshakeLibravatar Stefan Zager1-0/+12
It has been observed that curl_multi_timeout may return a very long timeout value (e.g., 294 seconds and some usec) just before curl_multi_fdset returns no file descriptors for reading. The upshot is that select() will hang for a long time -- long enough for an https handshake to be dropped. The observed behavior is that the git command will hang at the terminal and never transfer any data. This patch is a workaround for a probable bug in libcurl. The bug only seems to manifest around a very specific set of circumstances: - curl version (from curl/curlver.h): #define LIBCURL_VERSION_NUM 0x071307 - git-remote-https running on an ubuntu-lucid VM. - Connecting through squid proxy running on another VM. Interestingly, the problem doesn't manifest if a host connects through squid proxy running on localhost; only if the proxy is on a separate VM (not sure if the squid host needs to be on a separate physical machine). That would seem to suggest that this issue is timing-sensitive. This patch is more or less in line with a recommendation in the curl docs about how to behave when curl_multi_fdset doesn't return and file descriptors: http://curl.haxx.se/libcurl/c/curl_multi_fdset.html Signed-off-by: Stefan Zager <szager@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: show targets of deleted symrefs, not sha1sLibravatar René Scharfe2-11/+13
git branch reports the abbreviated hash of the head commit of a deleted branch to make it easier for a user to undo the operation. For symref branches this doesn't help. Print the symref target instead for them. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: skip commit checks when deleting symref branchesLibravatar René Scharfe2-2/+17
Before a branch is deleted, we check that it points to a valid commit. With -d we also check that the commit is a merged; this check is not done with -D. The reason for that is that commits pointed to by branches should never go missing; if they do then something broke and it's better to stop instead of adding to the mess. And a non-merged commit may contain changes that are worth preserving, so we require the stronger option -D instead of -d to get rid of them. If a branch consists of a symref, these concerns don't apply. Deleting such a branch can't make a commit become unreferenced, so we don't need to check if it is merged, or even if it is actually a valid commit. Skip them in that case. This allows us to delete dangling symref branches. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: delete symref branch, not its targetLibravatar René Scharfe2-1/+12
If a branch that is to be deleted happens to be a symref to another branch, the current code removes the targeted branch instead of the one it was called for. Change this surprising behaviour and delete the symref branch instead. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: factor out delete_branch_config()Libravatar René Scharfe1-5/+10
Provide a small helper function for deleting branch config sections. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18branch: factor out check_branch_commit()Libravatar René Scharfe1-12/+21
Move the code to perform checks on the tip commit of a branch to its own function. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18format-patch tests: check quoting/encoding in To: and Cc: headersLibravatar Jan H. Schönherr1-32/+66
git-format-patch does currently not parse user supplied extra header values (e. g., --cc, --add-header) and just replays them. That forces users to add them RFC 2822/2047 conform in encoded form, e.g. --cc '=?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <...>' which is inconvenient. We would want to update git-format-patch to accept human-readable input --cc 'Jan H. Schönherr <...>' and handle the encoding, wrapping and quoting internally in the future, similar to what is already done in git-send-email. The necessary code should mostly exist in the code paths that handle the From: and Subject: headers. Whether we want to do this only for the git-format-patch options --to and --cc (and the corresponding config options) or also for user supplied headers via --add-header, is open for discussion. For now, add test_expect_failure tests for To: and Cc: headers as a reminder and fix tests that would otherwise fail should this get implemented. Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18format-patch: fix rfc2047 address encoding with respect to rfc822 specialsLibravatar Jan H. Schönherr2-18/+33
According to RFC 2047 and RFC 822, rfc2047 encoded words and and rfc822 quoted strings do not mix. Since add_rfc2047() no longer leaves RFC 822 specials behind, the quoting is also no longer necessary to create a standard-conforming mail. Remove the quoting, when RFC 2047 encoding takes place. This actually requires to refactor add_rfc2047() a bit, so that the different cases can be distinguished. With this patch, my own name gets correctly decoded as Jan H. Schönherr (without quotes) and not as "Jan H. Schönherr" (with quotes). Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18format-patch: make rfc2047 encoding more strictLibravatar Jan H. Schönherr3-12/+72
RFC 2047 requires more characters to be encoded than it is currently done. Especially, RFC 2047 distinguishes between allowed remaining characters in encoded words in addresses (From, To, etc.) and other headers, such as Subject. Make add_rfc2047() and is_rfc2047_special() location dependent and include all non-allowed characters to hopefully be RFC 2047 conformant. This especially fixes a problem, where RFC 822 specials (e. g. ".") were left unencoded in addresses, which was solved with a non-standard-conforming workaround in the past (which is going to be removed in a follow-up patch). Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18format-patch: introduce helper function last_line_length()Libravatar Jan H. Schönherr1-12/+13
Currently, an open-coded loop to calculate the length of the last line of a string buffer is used in multiple places. Move that code into a function of its own. Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18format-patch: do not wrap rfc2047 encoded headers too lateLibravatar Jan H. Schönherr2-33/+51
Encoded characters add more than one character at once to an encoded header. Include all characters that are about to be added in the length calculation for wrapping. Additionally, RFC 2047 imposes a maximum line length of 76 characters if that line contains an rfc2047 encoded word. Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18format-patch: do not wrap non-rfc2047 headers too earlyLibravatar Jan H. Schönherr2-27/+35
Do not wrap the second and later lines of non-rfc2047-encoded headers substantially before the 78 character limit. Instead of passing the remaining length of the first line as wrapping width, use the correct maximum length and tell strbuf_add_wrapped_bytes() how many characters of the first line are already used. Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18utf8: fix off-by-one wrapping of textLibravatar Jan H. Schönherr2-3/+3
The wrapping logic in strbuf_add_wrapped_text() does currently not allow lines that entirely fill the allowed width, instead it wraps the line one character too early. For example, the text "This is the sixth commit." formatted via "%w(11,1,2)" (wrap at 11 characters, 1 char indent of first line, 2 char indent of following lines) results in four lines: " This is", " the", " sixth", " commit." This is wrong, because " the sixth" is exactly 11 characters long, and thus allowed. Fix this by allowing the (width+1) character of a line to be a valid wrapping point if it is a whitespace character. Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-17Merge tag 'gitgui-0.17.0' of git://repo.or.cz/git-guiLibravatar Junio C Hamano15-37/+65
git-gui 0.17.0 * tag 'gitgui-0.17.0' of git://repo.or.cz/git-gui: git-gui 0.17 git-gui: Don't prepend the prefix if value looks like a full path git-gui: Detect full path when parsing arguments git-gui: remove .git/CHERRY_PICK_HEAD after committing git-gui: Fix a loose/lose mistake git-gui: Fix semi-working shortcuts for unstage and revert git-gui: de.po: translate "remote" as "extern" git-gui: de.po: translate "bare" as "bloß" git-gui: de.po: consistently add untranslated hook names within braces git-gui: preserve commit messages in utf-8 git-gui: open console when using --trace on windows git-gui: fix a typo in po/ files git-gui: Use PWD if it exists on Mac OS X git-gui: fix git-gui crash due to uninitialized variable
2012-10-17git-gui 0.17Libravatar Pat Thoyts1-1/+1
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2012-10-17git-gui: Don't prepend the prefix if value looks like a full pathLibravatar Andrew Wong1-2/+7
When argument parsing fails to detect a file name, "git-gui" will try to use the previously detected "head" as the file name. We should avoid prepending the prefix if "head" looks like a full path. Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2012-10-17git-gui: Detect full path when parsing argumentsLibravatar Andrew Wong1-1/+10
When running "git-gui blame" from a subfolder (which means prefix is non-empty), if we pass a full path as argument, the argument parsing will fail to recognize the argument as a file name, because prefix is prepended to the argument. This patch handles that scenario by adding an additional branch that checks the file name without using the prefix. Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2012-10-17Git 1.8.0-rc3Libravatar Junio C Hamano2-5/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-17Merge git://github.com/git-l10n/git-poLibravatar Junio C Hamano2-914/+913
* git://github.com/git-l10n/git-po: l10n: vi.po: update from v1.8.0-rc2-4-g42e55 l10n: Update Swedish translation (1964t0f0u)
2012-10-17Sync with 1.7.12.4Libravatar Junio C Hamano2-1/+25
2012-10-17Git 1.7.12.4Libravatar Junio C Hamano4-3/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-17Merge branch 'jk/maint-http-half-auth-push' into maintLibravatar Junio C Hamano3-6/+6
* jk/maint-http-half-auth-push: http: fix segfault in handle_curl_result