summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-05-22Merge branch 'ps/doc-packfile-vs-pack-file'Libravatar Junio C Hamano3-9/+9
Doc consistency updates. * ps/doc-packfile-vs-pack-file: doc: fix inconsistent spelling of "packfile" pack-protocol.txt: fix insconsistent spelling of "packfile" git-unpack-objects.txt: fix inconsistent spelling of "packfile" git-verify-pack.txt: fix inconsistent spelling of "packfile"
2015-05-22Merge branch 'sb/t1020-cleanup'Libravatar Junio C Hamano1-4/+7
There was a commented-out (instead of being marked to expect failure) test that documented a breakage that was fixed since the test was written; turn it into a proper test. * sb/t1020-cleanup: subdirectory tests: code cleanup, uncomment test
2015-05-22Merge branch 'lm/squelch-bg-progress'Libravatar Junio C Hamano1-1/+2
The controlling tty-based heuristics to squelch progress output did not consider that the process may not be talking to a tty at all (e.g. sending the progress to sideband #2). This is a finishing touch to a topic that is already in 'master'. * lm/squelch-bg-progress: progress: treat "no terminal" as being in the foreground
2015-05-22Merge branch 'jc/ignore-epipe-in-filter'Libravatar Junio C Hamano5-8/+32
Filter scripts were run with SIGPIPE disabled on the Git side, expecting that they may not read what Git feeds them to filter. We however treated a filter that does not read its input fully before exiting as an error. This changes semantics, but arguably in a good way. If a filter can produce its output without consuming its input using whatever magic, we now let it do so, instead of diagnosing it as a programming error. * jc/ignore-epipe-in-filter: filter_buffer_or_fd(): ignore EPIPE copy.c: make copy_fd() report its status silently
2015-05-22Merge branch 'mh/clone-verbosity-fix'Libravatar Junio C Hamano1-2/+2
Git 2.4 broke setting verbosity and progress levels on "git clone" with native transports. * mh/clone-verbosity-fix: clone: call transport_set_verbosity before anything else on the newly created transport
2015-05-22Merge branch 'pt/pull-tags-error-diag'Libravatar Junio C Hamano1-9/+0
There was a dead code that used to handle "git pull --tags" and show special-cased error message, which was made irrelevant when the semantics of the option changed back in Git 1.9 days. * pt/pull-tags-error-diag: pull: remove --tags error in no merge candidates case
2015-05-22Merge branch 'mh/lockfile-retry'Libravatar Junio C Hamano5-5/+125
Instead of dying immediately upon failing to obtain a lock, retry after a short while with backoff. * mh/lockfile-retry: lock_packed_refs(): allow retries when acquiring the packed-refs lock lockfile: allow file locking to be retried with a timeout
2015-05-22Merge branch 'jk/add-e-kill-editor'Libravatar Junio C Hamano2-1/+9
"git add -e" did not allow the user to abort the operation by killing the editor. * jk/add-e-kill-editor: add: check return value of launch_editor
2015-05-22Merge branch 'sg/completion-config'Libravatar Junio C Hamano2-24/+48
Code clean-up for completion script (in contrib/). * sg/completion-config: completion: simplify query for config variables completion: add a helper function to get config variables
2015-05-22Merge branch 'mh/ref-directory-file'Libravatar Junio C Hamano3-118/+312
The ref API did not handle cases where 'refs/heads/xyzzy/frotz' is removed at the same time as 'refs/heads/xyzzy' is added (or vice versa) very well. * mh/ref-directory-file: reflog_expire(): integrate lock_ref_sha1_basic() errors into ours ref_transaction_commit(): delete extra "the" from error message ref_transaction_commit(): provide better error messages rename_ref(): integrate lock_ref_sha1_basic() errors into ours lock_ref_sha1_basic(): improve diagnostics for ref D/F conflicts lock_ref_sha1_basic(): report errors via a "struct strbuf *err" verify_refname_available(): report errors via a "struct strbuf *err" verify_refname_available(): rename function refs: check for D/F conflicts among refs created in a transaction ref_transaction_commit(): use a string_list for detecting duplicates is_refname_available(): use dirname in first loop struct nonmatching_ref_data: store a refname instead of a ref_entry report_refname_conflict(): inline function entry_matches(): inline function is_refname_available(): convert local variable "dirname" to strbuf is_refname_available(): avoid shadowing "dir" variable is_refname_available(): revamp the comments t1404: new tests of ref D/F conflicts within transactions
2015-05-22Merge branch 'mh/write-refs-sooner-2.4'Libravatar Junio C Hamano3-33/+112
Multi-ref transaction support we merged a few releases ago unnecessarily kept many file descriptors open, risking to fail with resource exhaustion. This is for 2.4.x track. * mh/write-refs-sooner-2.4: ref_transaction_commit(): fix atomicity and avoid fd exhaustion ref_transaction_commit(): remove the local flags variable ref_transaction_commit(): inline call to write_ref_sha1() rename_ref(): inline calls to write_ref_sha1() from this function commit_ref_update(): new function, extracted from write_ref_sha1() write_ref_to_lockfile(): new function, extracted from write_ref_sha1() t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE update-ref: test handling large transactions properly ref_transaction_commit(): fix atomicity and avoid fd exhaustion ref_transaction_commit(): remove the local flags variable ref_transaction_commit(): inline call to write_ref_sha1() rename_ref(): inline calls to write_ref_sha1() from this function commit_ref_update(): new function, extracted from write_ref_sha1() write_ref_to_lockfile(): new function, extracted from write_ref_sha1() t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE update-ref: test handling large transactions properly
2015-05-22Merge branch 'mg/log-decorate-HEAD'Libravatar Junio C Hamano2-11/+22
The "log --decorate" enhancement in Git 2.4 that shows the commit at the tip of the current branch e.g. "HEAD -> master", did not work with --decorate=full. * mg/log-decorate-HEAD: log: do not shorten decoration names too early log: decorate HEAD with branch name under --decorate=full, too
2015-05-22Merge branch 'jk/asciidoc-markup-fix'Libravatar Junio C Hamano19-102/+107
Various documentation mark-up fixes to make the output more consistent in general and also make AsciiDoctor (an alternative formatter) happier. * jk/asciidoc-markup-fix: doc: convert AsciiDoc {?foo} to ifdef::foo[] doc: put example URLs and emails inside literal backticks doc: drop backslash quoting of some curly braces doc: convert \--option to --option doc/add: reformat `--edit` option doc: fix length of underlined section-title doc: fix hanging "+"-continuation doc: fix unquoted use of "{type}" doc: fix misrendering due to `single quote'
2015-05-22Merge branch 'jk/stripspace-asciidoctor-fix'Libravatar Junio C Hamano1-3/+3
A literal block in the tutorial had lines with unequal lengths to delimit it from the rest of the document, which choke GitHub's AsciiDoc renderer. * jk/stripspace-asciidoctor-fix: doc: fix unmatched code fences in git-stripspace
2015-05-22Merge branch 'ja/tutorial-asciidoctor-fix'Libravatar Junio C Hamano1-1/+1
A literal block in the tutorial had lines with unequal lengths to delimit it from the rest of the document, which choke GitHub's AsciiDoc renderer. * ja/tutorial-asciidoctor-fix: doc: fix unmatched code fences
2015-05-22Merge branch 'sg/help-subcommands'Libravatar Junio C Hamano1-5/+5
A preparatory clean-up step. * sg/help-subcommands: command-list.txt: fix whitespace inconsistency
2015-05-22Merge branch 'ps/bundle-verify-arg'Libravatar Junio C Hamano1-0/+8
"git bundle verify" did not diagnose extra parameters on the command line. * ps/bundle-verify-arg: bundle: verify arguments more strictly
2015-05-22Merge branch 'ls/http-ssl-cipher-list'Libravatar Junio C Hamano3-0/+24
Introduce http.<url>.SSLCipherList configuration variable to tweak the list of cipher suite to be used with libcURL when talking with https:// sites. * ls/http-ssl-cipher-list: http: add support for specifying an SSL cipher list
2015-05-22Merge branch 'dl/subtree-avoid-tricky-echo'Libravatar Junio C Hamano1-3/+10
"git subtree" script (in contrib/) used "echo -n" to produce progress messages in a non-portable way. * dl/subtree-avoid-tricky-echo: contrib/subtree: portability fix for string printing
2015-05-22Merge branch 'jk/skip-http-tests-under-no-curl'Libravatar Junio C Hamano8-35/+13
Test clean-up. * jk/skip-http-tests-under-no-curl: tests: skip dav http-push tests under NO_EXPAT=NoThanks t/lib-httpd.sh: skip tests if NO_CURL is defined
2015-05-22Merge branch 'dl/subtree-push-no-squash'Libravatar Junio C Hamano2-2/+2
"git subtree" script (in contrib/) does not have --squash option when pushing, but the documentation and help text pretended as if it did. * dl/subtree-push-no-squash: contrib/subtree: there's no push --squash
2015-05-22Merge branch 'sg/completion-omit-credential-helpers'Libravatar Junio C Hamano1-2/+2
The Git subcommand completion (in contrib/) listed credential helpers among candidates, which is not something the end user would invoke interatively. * sg/completion-omit-credential-helpers: completion: remove credential helpers from porcelain commands
2015-05-22Merge branch 'dl/branch-error-message'Libravatar Junio C Hamano1-3/+3
Error messages from "git branch" called remote-tracking branches as "remote branches". * dl/branch-error-message: branch: do not call a "remote-tracking branch" a "remote branch"
2015-05-22doc: fix inconsistent spelling of "packfile"Libravatar Patrick Steinhardt2-3/+3
Fix remaining instances where "pack-file" is used instead of "packfile". Some places remain where we still use "pack-file", This is the case when we explicitly refer to a file with a ".pack" extension as opposed to a data source providing a pack data stream. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-20filter_buffer_or_fd(): ignore EPIPELibravatar Junio C Hamano2-1/+16
We are explicitly ignoring SIGPIPE, as we fully expect that the filter program may not read our output fully. Ignore EPIPE that may come from writing to it as well. A new test was stolen from Jeff's suggestion. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-19copy.c: make copy_fd() report its status silentlyLibravatar Junio C Hamano3-7/+16
When copy_fd() function encounters errors, it emits error messages itself, which makes it impossible for callers to take responsibility for reporting errors, especially when they want to ignore certain errors. Move the error reporting to its callers in preparation. - copy_file() and copy_file_with_time() by indirection get their own calls to error(). - hold_lock_file_for_append(), when told to die on error, used to exit(128) relying on the error message from copy_fd(), but now it does its own die() instead. Note that the callers that do not pass LOCK_DIE_ON_ERROR need to be adjusted for this change, but fortunately there is none ;-) - filter_buffer_or_fd() has its own error() already, in addition to the message from copy_fd(), so this will change the output but arguably in a better way. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-19Third batch for 2.5 cycleLibravatar Junio C Hamano1-0/+81
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-19Merge branch 'sb/ref-lock-lose-lock-fd'Libravatar Junio C Hamano1-10/+5
The refs API uses ref_lock struct which had its own "int fd", even though the same file descriptor was in the lock struct it contains. Clean-up the code to lose this redundant field. * sb/ref-lock-lose-lock-fd: refs.c: remove lock_fd from struct ref_lock
2015-05-19Merge branch 'kn/cat-file-literally'Libravatar Junio C Hamano5-43/+188
Add the "--allow-unknown-type" option to "cat-file" to allow inspecting loose objects of an experimental or a broken type. * kn/cat-file-literally: t1006: add tests for git cat-file --allow-unknown-type cat-file: teach cat-file a '--allow-unknown-type' option cat-file: make the options mutually exclusive sha1_file: support reading from a loose object of unknown type
2015-05-19Merge branch 'nd/dwim-wildcards-as-pathspecs'Libravatar Junio C Hamano1-1/+3
A heuristic to help the "git <cmd> <revs> <pathspec>" command line convention to catch mistyped paths is to make sure all the non-rev parameters in the later part of the command line are names of the files in the working tree, but that means "git grep $str -- \*.c" must always be disambiguated with "--", because nobody sane will create a file whose name literally is asterisk-dot-see. Loosen the heuristic to declare that with a wildcard string the user likely meant to give us a pathspec. * nd/dwim-wildcards-as-pathspecs: pathspec: avoid the need of "--" when wildcard is used
2015-05-19Merge branch 'jc/merge'Libravatar Junio C Hamano10-112/+324
"git merge FETCH_HEAD" learned that the previous "git fetch" could be to create an Octopus merge, i.e. recording multiple branches that are not marked as "not-for-merge"; this allows us to lose an old style invocation "git merge <msg> HEAD $commits..." in the implementation of "git pull" script; the old style syntax can now be deprecated. * jc/merge: merge: deprecate 'git merge <message> HEAD <commit>' syntax merge: handle FETCH_HEAD internally merge: decide if we auto-generate the message early in collect_parents() merge: make collect_parents() auto-generate the merge message merge: extract prepare_merge_message() logic out merge: narrow scope of merge_names merge: split reduce_parents() out of collect_parents() merge: clarify collect_parents() logic merge: small leakfix and code simplification merge: do not check argc to determine number of remote heads merge: clarify "pulling into void" special case t5520: test pulling an octopus into an unborn branch t5520: style fixes merge: simplify code flow merge: test the top-level merge driver
2015-05-19Merge branch 'ph/rebase-i-redo'Libravatar Junio C Hamano2-0/+63
"git rebase -i" moved the "current" command from "todo" to "done" a bit too prematurely, losing a step when a "pick" did not even start. * ph/rebase-i-redo: rebase -i: redo tasks that die during cherry-pick
2015-05-19Merge branch 'jc/test-prereq-validate'Libravatar Junio C Hamano1-0/+9
Help us to find broken test script that splits the body part of the test by mistaken use of wrong kind of quotes. * jc/test-prereq-validate: test: validate prerequistes syntax
2015-05-19Merge branch 'bc/connect-plink'Libravatar Junio C Hamano2-22/+67
The connection initiation code for "ssh" transport tried to absorb differences between the stock "ssh" and Putty-supplied "plink" and its derivatives, but the logic to tell that we are using "plink" variants were too loose and falsely triggered when "plink" appeared anywhere in the path (e.g. "/home/me/bin/uplink/ssh"). * bc/connect-plink: connect: improve check for plink to reduce false positives t5601: fix quotation error leading to skipped tests connect: simplify SSH connection code path
2015-05-19Merge branch 'jk/test-chain-lint'Libravatar Junio C Hamano2-2/+2
Developer support to automatically detect broken &&-chain in the test scripts is now turned on by default. * jk/test-chain-lint: test-lib: turn on GIT_TEST_CHAIN_LINT by default t7502-commit.sh: fix a broken and-chain
2015-05-19Merge branch 'fg/document-commit-message-stripping'Libravatar Junio C Hamano1-4/+7
* fg/document-commit-message-stripping: Documentation: clarify how "git commit" cleans up the edited log message
2015-05-19Merge branch 'jk/stash-require-clean-index'Libravatar Junio C Hamano2-7/+16
"git stash pop/apply" forgot to make sure that not just the working tree is clean but also the index is clean. The latter is important as a stash application can conflict and the index will be used for conflict resolution. * jk/stash-require-clean-index: stash: require a clean index to apply t3903: avoid applying onto dirty index t3903: stop hard-coding commit sha1s
2015-05-19Merge branch 'jk/git-no-more-argv0-path-munging'Libravatar Junio C Hamano1-1/+0
We have prepended $GIT_EXEC_PATH and the path "git" is installed in (typically "/usr/bin") to $PATH when invoking subprograms and hooks for almost eternity, but the original use case the latter tried to support was semi-bogus (i.e. install git to /opt/foo/git and run it without having /opt/foo on $PATH), and more importantly it has become less and less relevant as Git grew more mainstream (i.e. the users would _want_ to have it on their $PATH). Stop prepending the path in which "git" is installed to users' $PATH, as that would interfere the command search order people depend on (e.g. they may not like versions of programs that are unrelated to Git in /usr/bin and want to override them by having different ones in /usr/local/bin and have the latter directory earlier in their $PATH). * jk/git-no-more-argv0-path-munging: stop putting argv[0] dirname at front of PATH
2015-05-19Merge branch 'jc/gitignore-precedence'Libravatar Junio C Hamano2-3/+17
core.excludesfile (defaulting to $XDG_HOME/git/ignore) is supposed to be overridden by repository-specific .git/info/exclude file, but the order was swapped from the beginning. This belatedly fixes it. * jc/gitignore-precedence: ignore: info/exclude should trump core.excludesfile
2015-05-19Merge branch 'nd/diff-i-t-a'Libravatar Junio C Hamano4-8/+38
After "git add -N", the path appeared in output of "git diff HEAD" and "git diff --cached HEAD", leading "git status" to classify it as "Changes to be committed". Such a path, however, is not yet to be scheduled to be committed. "git diff" showed the change to the path as modification, not as a "new file", in the header of its output. Treat such paths as "yet to be added to the index but Git already know about them"; "git diff HEAD" and "git diff --cached HEAD" should not talk about them, and "git diff" should show them as new files yet to be added to the index. * nd/diff-i-t-a: diff-lib.c: adjust position of i-t-a entries in diff
2015-05-19progress: treat "no terminal" as being in the foregroundLibravatar Jeff King1-1/+2
progress: treat "no terminal" as being in the foreground Commit 85cb890 (progress: no progress in background, 2015-04-13) avoids sending progress from background processes by checking that the process group id of the current process is the same as that of the controlling terminal. If we don't have a terminal, however, this check never succeeds, and we print no progress at all (until the final "done" message). This can be seen when cloning a large repository; instead of getting progress updates for "counting objects", it will appear to hang then print the final count. We can fix this by treating an error return from tcgetpgrp() as a signal to show the progress. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-19clone: call transport_set_verbosity before anything else on the newly ↵Libravatar Mike Hommey1-2/+2
created transport Commit 2879bc3 made the progress and verbosity options sent to remote helper earlier than they previously were. But nothing else after that would send updates if the value is changed later on with transport_set_verbosity. While for fetch and push, transport_set_verbosity is the first thing that is done after creating the transport, it was not the case for clone. So commit 2879bc3 broke changing progress and verbosity for clone, for urls requiring a remote helper only (so, not git:// urls, for instance). Moving transport_set_verbosity to just after the transport is created works around the issue. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-18subdirectory tests: code cleanup, uncomment testLibravatar Stefan Beller1-4/+7
Back when these tests were written, we wanted to make sure that Git notices it is in a bare repository and "git show -s HEAD" would refrain from complaining that HEAD might mean a file it sees in its current working directory (because it does not). But the version of Git back then didn't behave well, without (doubly) being told that it is inside a bare repository by exporting "GIT_DIR=.". The form of the test we originally wanted to have was left commented out as a reminder. Nowadays the test as originally intended works, so add it to the test suite. We'll keep the old test that explicitly sets GIT_DIR=. to make sure that use case will not regress. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-17pack-protocol.txt: fix insconsistent spelling of "packfile"Libravatar Patrick Steinhardt1-3/+3
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-17git-unpack-objects.txt: fix inconsistent spelling of "packfile"Libravatar Patrick Steinhardt1-2/+2
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-17git-verify-pack.txt: fix inconsistent spelling of "packfile"Libravatar Patrick Steinhardt1-1/+1
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-14lock_packed_refs(): allow retries when acquiring the packed-refs lockLibravatar Michael Haggerty3-1/+34
Currently, there is only one attempt to acquire any lockfile, and if the lock is held by another process, the locking attempt fails immediately. This is not such a limitation for loose reference files. First, they don't take long to rewrite. Second, most reference updates have a known "old" value, so if another process is updating a reference at the same moment that we are trying to lock it, then probably the expected "old" value will not longer be valid, and the update will fail anyway. But these arguments do not hold for packed-refs: * The packed-refs file can be large and take significant time to rewrite. * Many references are stored in a single packed-refs file, so it could be that the other process was changing a different reference than the one that we are interested in. Therefore, it is much more likely for there to be spurious lock conflicts in connection to the packed-refs file, resulting in unnecessary command failures. So, if the first attempt to lock the packed-refs file fails, continue retrying for a configurable length of time before giving up. The default timeout is 1 second. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-14lockfile: allow file locking to be retried with a timeoutLibravatar Michael Haggerty2-4/+91
Currently, there is only one attempt to lock a file. If it fails, the whole operation fails. But it might sometimes be advantageous to try acquiring a file lock a few times before giving up. So add a new function, hold_lock_file_for_update_timeout(), that allows a timeout to be specified. Make hold_lock_file_for_update() a thin wrapper around the new function. If timeout_ms is positive, then retry for at least that many milliseconds to acquire the lock. On each failed attempt, use select() to wait for a backoff time that increases quadratically (capped at 1 second) and has a random component to prevent two processes from getting synchronized. If timeout_ms is negative, retry indefinitely. In a moment we will switch to using the new function when locking packed-refs. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-14pull: remove --tags error in no merge candidates caseLibravatar Paul Tan1-9/+0
Since 441ed41 ("git pull --tags": error out with a better message., 2007-12-28), git pull --tags would print a different error message if git-fetch did not return any merge candidates: It doesn't make sense to pull all tags; you probably meant: git fetch --tags This is because at that time, git-fetch --tags would override any configured refspecs, and thus there would be no merge candidates. The error message was thus introduced to prevent confusion. However, since c5a84e9 (fetch --tags: fetch tags *in addition to* other stuff, 2013-10-30), git fetch --tags would fetch tags in addition to any configured refspecs. Hence, if any no merge candidates situation occurs, it is not because --tags was set. As such, this special error message is now irrelevant. To prevent confusion, remove this error message. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-14doc: convert AsciiDoc {?foo} to ifdef::foo[]Libravatar Jeff King1-2/+6
The former seems to just be syntactic sugar for the latter. And as it's sugar that AsciiDoctor doesn't understand, it would be nice to avoid it. Since there are only two spots, and the resulting source is not significantly harder to read, it's worth doing. Note that this does slightly affect the generated HTML (it has an extra newline), but the rendered result for both HTML and docbook should be the same (since the newline is not syntactically significant there). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>