summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-10-16Merge branch 'cc/quote-comments' into maintLibravatar Junio C Hamano1-5/+6
A no-op code-health maintenance. * cc/quote-comments: quote: move comment before sq_quote_buf() quote: fix broken sq_quote_buf() related comment
2015-10-16Merge branch 'es/worktree-add-cleanup' into maintLibravatar Junio C Hamano1-0/+0
A no-op code-health maintenance. * es/worktree-add-cleanup: t2026: rename worktree prune test
2015-10-16Merge branch 'tk/doc-interpret-trailers-grammo' into maintLibravatar Junio C Hamano1-1/+1
* tk/doc-interpret-trailers-grammo: Documentation/interpret-trailers: Grammar fix
2015-10-16Merge branch 'tk/typofix-connect-unknown-proto-error' into maintLibravatar Junio C Hamano1-1/+1
* tk/typofix-connect-unknown-proto-error: connect: fix typo in result string of prot_name()
2015-10-16Merge branch 'jk/asciidoctor-section-heading-markup-fix' into maintLibravatar Junio C Hamano2-2/+2
* jk/asciidoctor-section-heading-markup-fix: Documentation: fix section header mark-up
2015-10-16Merge branch 'nd/ls-remote-does-not-have-u-option' into maintLibravatar Junio C Hamano2-3/+2
* nd/ls-remote-does-not-have-u-option: ls-remote.txt: delete unsupported option
2015-10-16Merge branch 'jc/fsck-dropped-errors' into maintLibravatar Junio C Hamano2-5/+35
There were some classes of errors that "git fsck" diagnosed to its standard error that did not cause it to exit with non-zero status. * jc/fsck-dropped-errors: fsck: exit with non-zero when problems are found
2015-10-16Merge branch 'sb/http-flaky-test-fix' into maintLibravatar Junio C Hamano3-23/+1
A test script for the HTTP service had a timing dependent bug, which was fixed. * sb/http-flaky-test-fix: t5561: get rid of racy appending to logfile
2015-10-16Merge branch 'sb/perf-without-installed-git' into maintLibravatar Junio C Hamano1-0/+1
Performance-measurement tests did not work without an installed Git. * sb/perf-without-installed-git: t/perf: make runner work even if Git is not installed
2015-10-16Merge branch 'js/icase-wt-detection' into maintLibravatar Junio C Hamano1-1/+10
On a case insensitive filesystems, setting GIT_WORK_TREE variable using a random cases that does not agree with what the filesystem thinks confused Git that it wasn't inside the working tree. * js/icase-wt-detection: setup: fix "inside work tree" detection on case-insensitive filesystems
2015-10-16Merge branch 'pt/am-builtin' into maintLibravatar Junio C Hamano1-1/+12
When "git am" was rewritten as a built-in, it stopped paying attention to user.signingkey, which was fixed. * pt/am-builtin: am: configure gpg at startup
2015-10-16Merge branch 'mm/detach-at-HEAD-reflog' into maintLibravatar Junio C Hamano2-0/+19
After "git checkout --detach", "git status" reported a fairly useless "HEAD detached at HEAD", instead of saying at which exact commit. * mm/detach-at-HEAD-reflog: status: don't say 'HEAD detached at HEAD' t3203: test 'detached at' after checkout --detach
2015-10-16Merge branch 'gr/rebase-i-drop-warn' into maintLibravatar Junio C Hamano2-35/+46
"git rebase -i" had a minor regression recently, which stopped considering a line that begins with an indented '#' in its insn sheet not a comment, which is now fixed. * gr/rebase-i-drop-warn: rebase-i: loosen over-eager check_bad_cmd check rebase-i: explicitly accept tab as separator in commands
2015-10-16Merge branch 'dt/log-follow-config' into maintLibravatar Junio C Hamano2-4/+10
Description of the "log.follow" configuration variable in "git log" documentation is now also copied to "git config" documentation. * dt/log-follow-config: log: Update log.follow doc and add to config.txt
2015-10-16Merge branch 'ti/glibc-stdio-mutex-from-signal-handler' into maintLibravatar Junio C Hamano3-14/+34
Allocation related functions and stdio are unsafe things to call inside a signal handler, and indeed killing the pager can cause glibc to deadlock waiting on allocation mutex as our signal handler tries to free() some data structures in wait_for_pager(). Reduce these unsafe calls. * ti/glibc-stdio-mutex-from-signal-handler: pager: don't use unsafe functions in signal handlers
2015-10-16Merge branch 'jk/notes-dwim-doc' into maintLibravatar Junio C Hamano3-3/+12
The way how --ref/--notes to specify the notes tree reference are DWIMmed was not clearly documented. * jk/notes-dwim-doc: notes: correct documentation of DWIMery for notes references
2015-10-16Merge branch 'jk/make-findstring-makeflags-fix' into maintLibravatar Junio C Hamano1-2/+2
Customization to change the behaviour with "make -w" and "make -s" in our Makefile was broken when they were used together. * jk/make-findstring-makeflags-fix: Makefile: fix MAKEFLAGS tests with multiple flags
2015-10-16Merge branch 'jw/make-arflags-customizable' into maintLibravatar Junio C Hamano1-3/+6
The Makefile always runs the library archiver with hardcoded "crs" options, which was inconvenient for exotic platforms on which people want to use programs with totally different set of command line options. * jw/make-arflags-customizable: Makefile: allow $(ARFLAGS) specified from the command line
2015-10-16Merge branch 'jk/connect-clear-env' into maintLibravatar Junio C Hamano2-10/+49
The ssh transport, just like any other transport over the network, did not clear GIT_* environment variables, but it is possible to use SendEnv and AcceptEnv to leak them to the remote invocation of Git, which is not a good idea at all. Explicitly clear them just like we do for the local transport. * jk/connect-clear-env: git_connect: clarify conn->use_shell flag git_connect: clear GIT_* environment for ssh
2015-10-16Merge branch 'jk/blame-first-parent' into maintLibravatar Junio C Hamano2-1/+14
"git blame --first-parent v1.0..v2.0" was not rejected but did not limit the blame to commits on the first parent chain. * jk/blame-first-parent: blame: handle --first-parent
2015-10-16Merge branch 'mm/keyid-docs' into maintLibravatar Junio C Hamano10-29/+47
Very small number of options take a parameter that is optional (which is not a great UI element as they can only appear at the end of the command line). Add notice to documentation of each and every one of them. * mm/keyid-docs: Documentation: explain optional arguments better Documentation/grep: fix documentation of -O Documentation: use 'keyid' consistently, not 'key-id'
2015-10-16Merge branch 'pt/pull-builtin' into maintLibravatar Junio C Hamano3-3/+3
* pt/pull-builtin: pull: enclose <options> in brackets in the usage string merge: grammofix in please-commit-before-merge message
2015-10-16pull: enclose <options> in brackets in the usage stringLibravatar Alex Henrie1-1/+1
All the other placeholders are already shown that way. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-07quote: move comment before sq_quote_buf()Libravatar Christian Couder1-5/+5
A big comment at the beginning of quote.c is really related to sq_quote_buf(), so let's move it in front of this function. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-07quote: fix broken sq_quote_buf() related commentLibravatar Christian Couder1-0/+1
Since 77d604c (Enhanced sq_quote(), 10 Oct 2005), the comment at the beginning of quote.c is broken. Let's fix it. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-07Documentation/interpret-trailers: Grammar fixLibravatar Tobias Klauser1-1/+1
Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-07t2026: rename worktree prune testLibravatar Michael J Gruber1-0/+0
Linked checkouts are known under the name worktree, now. Rename the test accordingly. Specifically, this avoids the confusion that t2026 is actually not about pruning in or with linked checkouts aka worktress but about pruning worktrees, i.e. about "git worktree prune" rather than "git prune". Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-07log: Update log.follow doc and add to config.txtLibravatar Eric N. Vander Weele2-4/+10
Documentation/config.txt does not include the documentation for log.follow that is in Documentation/git-log.txt. This commit adds the log.follow documentation to config.txt and also updates the wording to be consistent with the format that is followed by other boolean configuration variables. Signed-off-by: Eric N. Vander Weele <ericvw@gmail.com> Acked-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-05rebase-i: loosen over-eager check_bad_cmd checkLibravatar Matthieu Moy2-33/+44
804098bb (git rebase -i: add static check for commands and SHA-1, 2015-06-29) tried to check all insns before running any in the todo list, but it did so by implementing its own parser that is a lot stricter than necessary. We used to allow lines that are indented (including comment lines), and we used to allow a whitespace between the insn and the commit object name to be HT, among other things, that are flagged as an invalid line by mistake. Fix this by using the same tokenizer that is used to parse the todo list file in the new check. Whether it's a good thing to accept indented comments is debatable (other commands like "git commit" do not accept them), but we already accepted them in the past, and some people and scripts rely on this behavior. Also, a line starting with space followed by a '#' cannot have any meaning other than being a comment, hence it doesn't harm to accept them as comments. Largely based on patch by: Junio C Hamano <gitster@pobox.com> [jc: updated test with quickfix from Torsten Bögershausen] Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-02merge: grammofix in please-commit-before-merge messageLibravatar Alex Henrie2-2/+2
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-02rebase-i: explicitly accept tab as separator in commandsLibravatar Matthieu Moy1-2/+2
The git-rebase-todo is parsed several times with different parsers. In principle, the user input is normalized by transform_todo_ids and further parsing can be stricter. In case the user wrote pick deadbeef<TAB>commit message the parser of transform_todo_ids was considering the sha1 to be "deadbeef<TAB>commit", and was leaving the tab in the transformed sheet. In practice, this went unnoticed since the actual command interpretation was done later in do_next which did accept the tab as a separator. Make it explicit in the code of transform_todo_ids that tabs are accepted. This way, code that mimicks it will also accept tabs as separator. A similar construct appears in skip_unnecessary_picks, but this one comes after transform_todo_ids, hence reads the normalized format, so it needs not be changed. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-02status: don't say 'HEAD detached at HEAD'Libravatar Matthieu Moy2-1/+7
After using "git checkout --detach", the reflog is left with an entry like checkout: moving from ... to HEAD This message is parsed to generate the 'HEAD detached at' message in 'git branch' and 'git status', which leads to the not-so-useful message 'HEAD detached at HEAD'. Instead, when parsing such reflog entry, resolve HEAD to the corresponding commit in the reflog, so that the message becomes 'HEAD detached at $sha1'. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-02t3203: test 'detached at' after checkout --detachLibravatar Matthieu Moy1-0/+13
This currently fails: the output is 'HEAD detached at HEAD'. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-30am: configure gpg at startupLibravatar Renee Margaret McConahy1-1/+12
The new builtin am ignores the user.signingkey variable: gpg is being called with the committer details as the key ID, which may not be correct. git_gpg_config is responsible for handling that variable and is expected to be called on initialization by any modules that use gpg. Signed-off-by: Renee Margaret McConahy <nepella@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Git 2.6.1Libravatar Junio C Hamano4-3/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Sync with v2.5.4Libravatar Junio C Hamano29-30/+486
2015-09-28Git 2.5.4Libravatar Junio C Hamano4-3/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Sync with 2.4.10Libravatar Junio C Hamano28-29/+466
2015-09-28Git 2.4.10Libravatar Junio C Hamano4-3/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Sync with 2.3.10Libravatar Junio C Hamano27-28/+446
2015-09-28Git 2.3.10Libravatar Junio C Hamano4-3/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Merge branch 'jk/xdiff-memory-limits' into maint-2.3Libravatar Junio C Hamano11-26/+57
2015-09-28merge-file: enforce MAX_XDIFF_SIZE on incoming filesLibravatar Jeff King1-1/+2
The previous commit enforces MAX_XDIFF_SIZE at the interfaces to xdiff: xdi_diff (which calls xdl_diff) and ll_xdl_merge (which calls xdl_merge). But we have another direct call to xdl_merge in merge-file.c. If it were written today, this probably would just use the ll_merge machinery. But it predates that code, and uses slightly different options to xdl_merge (e.g., ZEALOUS_ALNUM). We could try to abstract out an xdi_merge to match the existing xdi_diff, but even that is difficult. Rather than simply report error, we try to treat large files as binary, and that distinction would happen outside of xdi_merge. The simplest fix is to just replicate the MAX_XDIFF_SIZE check in merge-file.c. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28xdiff: reject files larger than ~1GBLibravatar Jeff King3-1/+14
The xdiff code is not prepared to handle extremely large files. It uses "int" in many places, which can overflow if we have a very large number of lines or even bytes in our input files. This can cause us to produce incorrect diffs, with no indication that the output is wrong. Or worse, we may even underallocate a buffer whose size is the result of an overflowing addition. We're much better off to tell the user that we cannot diff or merge such a large file. This patch covers both cases, but in slightly different ways: 1. For merging, we notice the large file and cleanly fall back to a binary merge (which is effectively "we cannot merge this"). 2. For diffing, we make the binary/text distinction much earlier, and in many different places. For this case, we'll use the xdi_diff as our choke point, and reject any diff there before it hits the xdiff code. This means in most cases we'll die() immediately after. That's not ideal, but in practice we shouldn't generally hit this code path unless the user is trying to do something tricky. We already consider files larger than core.bigfilethreshold to be binary, so this code would only kick in when that is circumvented (either by bumping that value, or by using a .gitattribute to mark a file as diffable). In other words, we can avoid being "nice" here, because there is already nice code that tries to do the right thing. We are adding the suspenders to the nice code's belt, so notice when it has been worked around (both to protect the user from malicious inputs, and because it is better to die() than generate bogus output). The maximum size was chosen after experimenting with feeding large files to the xdiff code. It's just under a gigabyte, which leaves room for two obvious cases: - a diff3 merge conflict result on files of maximum size X could be 3*X plus the size of the markers, which would still be only about 3G, which fits in a 32-bit int. - some of the diff code allocates arrays of one int per record. Even if each file consists only of blank lines, then a file smaller than 1G will have fewer than 1G records, and therefore the int array will fit in 4G. Since the limit is arbitrary anyway, I chose to go under a gigabyte, to leave a safety margin (e.g., we would not want to overflow by allocating "(records + 1) * sizeof(int)" or similar. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28react to errors in xdi_diffLibravatar Jeff King7-24/+41
When we call into xdiff to perform a diff, we generally lose the return code completely. Typically by ignoring the return of our xdi_diff wrapper, but sometimes we even propagate that return value up and then ignore it later. This can lead to us silently producing incorrect diffs (e.g., "git log" might produce no output at all, not even a diff header, for a content-level diff). In practice this does not happen very often, because the typical reason for xdiff to report failure is that it malloc() failed (it uses straight malloc, and not our xmalloc wrapper). But it could also happen when xdiff triggers one our callbacks, which returns an error (e.g., outf() in builtin/rerere.c tries to report a write failure in this way). And the next patch also plans to add more failure modes. Let's notice an error return from xdiff and react appropriately. In most of the diff.c code, we can simply die(), which matches the surrounding code (e.g., that is what we do if we fail to load a file for diffing in the first place). This is not that elegant, but we are probably better off dying to let the user know there was a problem, rather than simply generating bogus output. We could also just die() directly in xdi_diff, but the callers typically have a bit more context, and can provide a better message (and if we do later decide to pass errors up, we're one step closer to doing so). There is one interesting case, which is in diff_grep(). Here if we cannot generate the diff, there is nothing to match, and we silently return "no hits". This is actually what the existing code does already, but we make it a little more explicit. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28Merge branch 'jk/transfer-limit-redirection' into maint-2.3Libravatar Junio C Hamano6-15/+78
2015-09-28Merge branch 'jk/transfer-limit-protocol' into maint-2.3Libravatar Junio C Hamano13-1/+306
2015-09-28Git 2.6Libravatar Junio C Hamano2-1/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28ls-remote.txt: delete unsupported optionLibravatar Nguyễn Thái Ngọc Duy2-3/+2
-u <exec> has never been supported, but it was mentioned since 0a2bb55 (git ls-remote: make usage string match manpage - 2008-11-11). Nobody has complained about it for seven years, it's probably safe to say nobody cares. So let's remove "-u" in documents instead of adding code to support it. While at there, fix --upload-pack syntax too. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-28setup: fix "inside work tree" detection on case-insensitive filesystemsLibravatar Johannes Schindelin1-1/+10
Git has a config variable to indicate that it is operating on a file system that is case-insensitive: core.ignoreCase. But the `dir_inside_of()` function did not respect that. As a result, if Git's idea of the current working directory disagreed in its upper/lower case with the `GIT_WORK_TREE` variable (e.g. `C:\test` vs `c:\test`) the user would be greeted by the error message fatal: git-am cannot be used without a working tree. when trying to run a rebase. This fixes https://github.com/git-for-windows/git/issues/402 (reported by Daniel Harding). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>