summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-10-17Merge branch 'db/doc-custom-xmlto' into maintLibravatar Junio C Hamano1-2/+3
* db/doc-custom-xmlto: Documentation/Makefile: Allow custom XMLTO binary
2012-10-13Fix spelling error in post-receive-email hookLibravatar Richard Fearn1-1/+1
Signed-off-by: Richard Fearn <richardfearn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-12gitweb.cgi: fix "comitter_tz" typo in feedLibravatar Dylan Alex Simon1-1/+1
gitweb's feeds sometimes contained committer timestamps in the wrong timezone due to a misspelling. Signed-off-by: Dylan Simon <dylan@dylex.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-10attr: a note about the order of .gitattributes lookupLibravatar Nguyen Thai Ngoc Duy1-0/+5
This is the documentation part of 1a9d7e9 (attr.c: read .gitattributes from index as well. - 2007-08-14) 06f33c1 (Read attributes from the index that is being checked out - 2009-03-13) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-09Merge branch 'maint' of git://github.com/git-l10n/git-po into maintLibravatar Junio C Hamano1-7/+7
* 'maint' of git://github.com/git-l10n/git-po: l10n: de.po: fix a few minor typos
2012-10-08Git 1.7.12.3Libravatar Junio C Hamano3-2/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-08Merge branch 'os/commit-submodule-ignore' into maintLibravatar Junio C Hamano1-0/+1
"git status" honored the ignore=dirty settings in .gitmodules but "git commit" didn't. * os/commit-submodule-ignore: commit: pay attention to submodule.$name.ignore in .gitmodules
2012-10-08Merge branch 'jk/receive-pack-unpack-error-to-pusher' into maintLibravatar Junio C Hamano2-5/+32
"git receive-pack" (the counterpart to "git push") did not give progress output while processing objects it received to the puser when run over the smart-http protocol. * jk/receive-pack-unpack-error-to-pusher: receive-pack: drop "n/a" on unpacker errors receive-pack: send pack-processing stderr over sideband receive-pack: redirect unpack-objects stdout to /dev/null
2012-10-08Merge branch 'rt/maint-clone-single' into maintLibravatar Junio C Hamano3-18/+218
A repository created with "git clone --single" had its fetch refspecs set up just like a clone without "--single", leading the subsequent "git fetch" to slurp all the other branches, defeating the whole point of specifying "only this branch". * rt/maint-clone-single: clone --single: limit the fetch refspec to fetched branch
2012-10-08Merge branch 'jc/blame-follows-renames' into maintLibravatar Junio C Hamano1-0/+6
It was unclear in the documentation for "git blame" that it is unnecessary for users to use the "--follow" option. * jc/blame-follows-renames: git blame: document that it always follows origin across whole-file renames
2012-10-08Merge branch 'lt/mailinfo-handle-attachment-more-sanely' into maintLibravatar Junio C Hamano1-11/+0
A patch attached as application/octet-stream (e.g. not text/*) were mishandled, not correctly honoring Content-Transfer-Encoding (e.g. base64). * lt/mailinfo-handle-attachment-more-sanely: mailinfo: don't require "text" mime type for attachments
2012-10-04l10n: de.po: fix a few minor typosLibravatar Simon Ruderich1-7/+7
Signed-off-by: Simon Ruderich <simon@ruderich.org> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2012-10-02Start preparing for 1.7.12.3Libravatar Junio C Hamano2-1/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-02Merge branch 'rr/maint-submodule-unknown-cmd' into maintLibravatar Junio C Hamano3-4/+11
"git submodule frotz" was not diagnosed as "frotz" being an unknown subcommand to "git submodule"; the user instead got a complaint that "git submodule status" was run with an unknown path "frotz". * rr/maint-submodule-unknown-cmd: submodule: if $command was not matched, don't parse other args
2012-10-02Merge branch 'sp/maint-http-enable-gzip' into maintLibravatar Junio C Hamano3-3/+5
"git fetch" over http advertised that it supports "deflate", which is much less common, and did not advertise more common "gzip" on its Accept-Encoding header. * sp/maint-http-enable-gzip: Enable info/refs gzip decompression in HTTP client
2012-10-02Merge branch 'sp/maint-http-info-refs-no-retry' into maintLibravatar Junio C Hamano1-16/+2
"git fetch" over http had an old workaround for an unlikely server misconfiguration; it turns out that this hurts debuggability of the configuration in general, and has been reverted. * sp/maint-http-info-refs-no-retry: Revert "retry request without query when info/refs?query fails"
2012-10-02l10n: Fix to Swedish translationLibravatar Peter Krefting1-2/+2
Fix bad translation of "Receiving objects". Signed-off-by: Peter Krefting <peter@softwolves.pp.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-30mailinfo: don't require "text" mime type for attachmentsLibravatar Linus Torvalds1-11/+0
Currently "git am" does insane things if the mbox it is given contains attachments with a MIME type that aren't "text/*". In particular, it will still decode them, and pass them "one line at a time" to the mail body filter, but because it has determined that they aren't text (without actually looking at the contents, just at the mime type) the "line" will be the encoding line (eg 'base64') rather than a line of *content*. Which then will cause the text filtering to fail, because we won't correctly notice when the attachment text switches from the commit message to the actual patch. Resulting in a patch failure, even if patch may be a perfectly well-formed attachment, it's just that the message type may be (for example) "application/octet-stream" instead of "text/plain". Just remove all the bogus games with the message_type. The only difference that code creates is how the data is passed to the filter function (chunked per-pred-code line or per post-decode line), and that difference is *wrong*, since chunking things per pre-decode line can never be a sensible operation, and cannot possibly matter for binary data anyway. This code goes all the way back to March of 2007, in commit 87ab79923463 ("builtin-mailinfo.c infrastrcture changes"), and apparently Don used to pass random mbox contents to git. However, the pre-decode vs post-decode logic really shouldn't matter even for that case, and more importantly, "I fed git am crap" is not a valid reason to break *real* patch attachments. If somebody really cares, and determines that some attachment is binary data (by looking at the data, not the MIME-type), the whole attachment should be dismissed, rather than fed in random-sized chunks to "handle_filter()". Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Don Zickus <dzickus@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29Git 1.7.12.2Libravatar Junio C Hamano3-2/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29Merge branch 'maint' of git://github.com/git-l10n/git-po into maintLibravatar Junio C Hamano2-28/+28
Update German and Simplified Chinese translations. * 'maint' of git://github.com/git-l10n/git-po: l10n: de.po: correct translation of a 'rebase' message l10n: Improve many translation for zh_CN l10n: Unify the translation for '(un)expected'
2012-09-29Merge branch 'jc/maint-log-grep-all-match-1' into maintLibravatar Junio C Hamano6-25/+217
* jc/maint-log-grep-all-match-1: grep.c: make two symbols really file-scope static this time t7810-grep: test --all-match with multiple --grep and --author options t7810-grep: test interaction of multiple --grep and --author options t7810-grep: test multiple --author with --all-match t7810-grep: test multiple --grep with and without --all-match t7810-grep: bring log --grep tests in common form grep.c: mark private file-scope symbols as static log: document use of multiple commit limiting options log --grep/--author: honor --all-match honored for multiple --grep patterns grep: show --debug output only once grep: teach --debug option to dump the parse tree
2012-09-29Merge branch 'jc/maint-mailinfo-mime-attr' into maintLibravatar Junio C Hamano6-4/+32
* jc/maint-mailinfo-mime-attr: mailinfo: do not concatenate charset= attribute values from mime headers
2012-09-28Merge branch 'l10n-thynson' of git://github.com/thynson/git-po-zh_CN into maintLibravatar Jiang Xin1-23/+23
* 'l10n-thynson' of git://github.com/thynson/git-po-zh_CN: l10n: Improve many translation for zh_CN l10n: Unify the translation for '(un)expected'
2012-09-28Merge branch 'maint' of https://github.com/ralfth/git-po-de into maintLibravatar Jiang Xin1-5/+5
* 'maint' of https://github.com/ralfth/git-po-de: l10n: de.po: correct translation of a 'rebase' message
2012-09-27l10n: de.po: correct translation of a 'rebase' messageLibravatar Ralf Thielow1-5/+5
Noticed-by: Sascha Cunz <sascha-ml@babbelbox.org> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2012-09-25submodule: if $command was not matched, don't parse other argsLibravatar Ramkumar Ramachandra3-4/+11
"git submodule" command DWIMs the command line and assumes a unspecified action word for 'status' action. This is a UI mistake that leads to a confusing behaviour. A mistyped command name is instead treated as a request for 'status' of the submodule with that name, e.g. $ git submodule show error: pathspec 'show' did not match any file(s) known to git. Did you forget to 'git add'? Stop DWIMming an unknown or mistyped subcommand name as pathspec given to unspelled "status" subcommand. "git submodule" without any argument is still interpreted as "git submodule status", but its value is questionable. Adjust t7400 to match, and stop advertising the default subcommand being 'status' which does not help much in practice, other than promoting laziness and confusion. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-25Revert "completion: fix shell expansion of items"Libravatar Jeff King1-8/+1
This reverts commit 25ae7cfd19c8f21721363c64163cd5d9d1135b20. That patch does fix expansion of weird variables in some simple tests, but it also seems to break other things, like expansion of refs by "git checkout". While we're sorting out the correct solution, we are much better with the original bug (people with metacharacters in their completions occasionally see an error message) than the current bug (ref completion does not work at all). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-24Start preparation for 1.7.12.2Libravatar Junio C Hamano2-1/+33
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-24Merge branch 'jc/maint-blame-no-such-path' into maintLibravatar Junio C Hamano2-17/+74
Even during a conflicted merge, "git blame $path" always meant to blame uncommitted changes to the "working tree" version; make it more useful by showing cleanly merged parts as coming from the other branch that is being merged. This incidentally fixes an unrelated problem on a case insensitive filesystem, where "git blame MAKEFILE" run in a history that has "Makefile" but not "MAKEFILE" did not say "No such file MAKEFILE in HEAD" but pretended as if "MAKEFILE" was a newly added file. * jc/maint-blame-no-such-path: blame: allow "blame file" in the middle of a conflicted merge blame $path: avoid getting fooled by case insensitive filesystems
2012-09-24Merge branch 'dj/fetch-all-tags' into maintLibravatar Junio C Hamano7-39/+92
"git fetch --all", when passed "--no-tags", did not honor the "--no-tags" option while fetching from individual remotes (the same issue existed with "--tags", but combination "--all --tags" makes much less sense than "--all --no-tags"). * dj/fetch-all-tags: fetch --all: pass --tags/--no-tags through to each remote submodule: use argv_array instead of hand-building arrays fetch: use argv_array instead of hand-building arrays argv-array: fix bogus cast when freeing array argv-array: add pop function
2012-09-24Improve the description of GIT_PS1_SHOWUPSTREAMLibravatar Jonathan "Duke" Leto1-3/+4
Describe what '=' means in the output of __git_ps1 when using GIT_PS1_SHOWUPSTREAM, which was not previously described. Signed-off-by: Jonathan "Duke" Leto <jonathan@leto.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-24commit: pay attention to submodule.$name.ignore in .gitmodulesLibravatar Orgad Shaneh1-0/+1
"git status" does not list a submodule with uncommitted working tree files as modified when "submodule.$name.ignore" is set to "dirty" in in-tree ".gitmodules" file. Both status and commit honor the setting in $GIT_DIR/config, but "commit" does not pick it up from .gitmodules, which is inconsistent. Teach "git commit" to pay attention to the setting in .gitmodules as well. Signed-off-by: Orgad Shaneh <orgads@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-21git blame: document that it always follows origin across whole-file renamesLibravatar Junio C Hamano1-0/+6
Make it clear to people who (rightly or wrongly) think that the "--follow" option should follow origin across while-file renames that we already do so. That would explain the output that they see when they do give the "--follow" option to the command. We may or may not want to do a "--no-follow" patch as a follow-up, but that is a separate topic. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-21receive-pack: drop "n/a" on unpacker errorsLibravatar Jeff King2-2/+2
The output from git push currently looks like this: $ git push dest HEAD fatal: [some message from index-pack] error: unpack failed: index-pack abnormal exit To dest ! [remote rejected] HEAD -> master (n/a (unpacker error)) That n/a is meant to be "the per-ref status is not available" but the nested parentheses just make it look ugly. Let's turn the final line into just: ! [remote rejected] HEAD -> master (unpacker error) Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-21receive-pack: send pack-processing stderr over sidebandLibravatar Jeff King1-2/+24
Receive-pack invokes either unpack-objects or index-pack to handle the incoming pack. However, we do not redirect the stderr of the sub-processes at all, so it is never seen by the client. From the initial thread adding sideband support, which is here: http://thread.gmane.org/gmane.comp.version-control.git/139471 it is clear that some messages are specifically kept off the sideband (with the assumption that they are of interest only to an administrator, not the client). The stderr of the subprocesses is mentioned in the thread, but it's unclear if they are included in that group, or were simply forgotten. However, there are a few good reasons to show them to the client: 1. In many cases, they are directly about the incoming packfile (e.g., fsck warnings with --strict, corruption in the packfile, etc). Without these messages, the client just gets "unpacker error" with no extra useful diagnosis. 2. No matter what the cause, we are probably better off showing the errors to the client. If the client and the server admin are not the same entity, it is probably much easier for the client to cut-and-paste the errors they see than for the admin to try to dig them out of a log and correlate them with a particular session. 3. Users of the ssh transport typically already see these stderr messages, as the remote's stderr is copied literally by ssh. This brings other transports (http, and push-over-git if you are crazy enough to enable it) more in line with ssh. As a bonus for ssh users, because the messages are now fed through the sideband and printed by the local git, they will have "remote:" prepended and be properly interleaved with any local output to stderr. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-21receive-pack: redirect unpack-objects stdout to /dev/nullLibravatar Jeff King1-1/+6
The unpack-objects command should not generally produce any output on stdout. However, if it's given extra input after the packfile, it will spew the remainder to stdout. When called by receive-pack, this means we will break protocol, since our stdout is connected to the remote send-pack. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20Merge branch 'nd/maint-diffstat-summary' into maintLibravatar Junio C Hamano1-6/+4
* nd/maint-diffstat-summary: Revert diffstat back to English
2012-09-20Merge branch 'jw/doc-commit-title' into maintLibravatar Junio C Hamano7-22/+31
* jw/doc-commit-title: Documentation: describe subject more precisely
2012-09-20Merge branch 'dg/run-command-child-cleanup' into maintLibravatar Junio C Hamano1-6/+7
* dg/run-command-child-cleanup: run-command.c: fix broken list iteration in clear_child_for_cleanup
2012-09-20Merge branch 'jc/mailinfo-RE' into maintLibravatar Junio C Hamano1-1/+3
* jc/mailinfo-RE: mailinfo: strip "RE: " prefix
2012-09-20Merge branch 'sn/ls-remote-get-url-doc' into maintLibravatar Junio C Hamano2-1/+6
* sn/ls-remote-get-url-doc: ls-remote: document the '--get-url' option
2012-09-20Merge branch 'nd/log-n-doc' into maintLibravatar Junio C Hamano2-5/+4
* nd/log-n-doc: doc: move rev-list option -<n> from git-log.txt to rev-list-options.txt
2012-09-20Merge branch 'nd/maint-remote-remove' into maintLibravatar Junio C Hamano5-9/+10
* nd/maint-remote-remove: remote: prefer subcommand name 'remove' to 'rm'
2012-09-20grep.c: make two symbols really file-scope static this timeLibravatar Junio C Hamano1-2/+2
Adding a declaration at the beginning is not sufficient for obvious reasons. The definition has to be made static. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20clone --single: limit the fetch refspec to fetched branchLibravatar Ralf Thielow3-18/+218
After running "git clone --single", the resulting repository has the usual default "+refs/heads/*:refs/remotes/origin/*" wildcard fetch refspec installed, which means that a subsequent "git fetch" will end up grabbing all the other branches. Update the fetch refspec to cover only the singly cloned ref instead to correct this. That means: If "--single" is used without "--branch" or "--mirror", the fetch refspec covers the branch on which remote's HEAD points to. If "--single" is used with "--branch", it'll cover only the branch specified in the "--branch" option. If "--single" is combined with "--mirror", then it'll cover all refs of the cloned repository. If "--single" is used with "--branch" that specifies a tag, then it'll cover only the ref for this tag. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20Documentation: Document signature showing optionsLibravatar Stephen Boyd2-0/+7
The pretty formats for GPG signatures were introduced but never documented. Use the documentation from the commit that introduced them. Do the same for the --show-signature option added to git log and friends. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20Enable info/refs gzip decompression in HTTP clientLibravatar Shawn O. Pearce3-3/+5
Some HTTP servers try to use gzip compression on the /info/refs request to save transfer bandwidth. Repositories with many tags may find the /info/refs request can be gzipped to be 50% of the original size due to the few but often repeated bytes used (hex SHA-1 and commonly digits in tag names). For most HTTP requests enable "Accept-Encoding: gzip" ensuring the /info/refs payload can use this encoding format. Only request gzip encoding from servers. Although deflate is supported by libcurl, most servers have standardized on gzip encoding for compression as that is what most browsers support. Asking for deflate increases request sizes by a few bytes, but is unlikely to ever be used by a server. Disable the Accept-Encoding header on probe RPCs as response bodies are supposed to be exactly 4 bytes long, "0000". The HTTP headers requesting and indicating compression use more space than the data transferred in the body. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20Revert "retry request without query when info/refs?query fails"Libravatar Shawn O. Pearce1-16/+2
This reverts commit 703e6e76a14825e5b0c960d525f34e607154b4f7. Retrying without the query parameter was added as a workaround for a single broken HTTP server at git.debian.org[1]. The server was misconfigured to route every request with a query parameter into gitweb.cgi. Admins fixed the server's configuration within 16 hours of the bug report to the Git mailing list, but we still patched Git with this fallback and have been paying for it since. Most Git hosting services configure the smart HTTP protocol and the retry logic confuses users when there is a transient HTTP error as Git dropped the real error from the smart HTTP request. Removing the retry makes root causes easier to identify. [1] http://thread.gmane.org/gmane.comp.version-control.git/137609 Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20completion: fix shell expansion of itemsLibravatar Felipe Contreras1-1/+8
As reported by Jeroen Meijer[1]; the current code doesn't deal properly with items (tags, branches, etc.) that have ${} in them because they get expaned by bash while using compgen. A simple solution is to quote the items so they get expanded properly (\$\{\}). In order to achieve that I took bash-completion's quote() function, which is rather simple, and renamed it to __git_quote() as per Jeff King's suggestion. Solves the original problem for me. [1] http://article.gmane.org/gmane.comp.version-control.git/201596 Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-19Documentation/Makefile: Allow custom XMLTO binaryLibravatar Dave Borowitz1-2/+3
Signed-off-by: Dave Borowitz <dborowitz@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>