summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-10-14Merge branch 'nd/ls-remote-does-not-have-u-option'Libravatar Junio C Hamano2-3/+2
* nd/ls-remote-does-not-have-u-option: ls-remote.txt: delete unsupported option
2015-10-14Merge branch 'jk/asciidoctor-section-heading-markup-fix'Libravatar Junio C Hamano2-2/+2
* jk/asciidoctor-section-heading-markup-fix: Documentation: fix section header mark-up
2015-10-14Merge branch 'tk/typofix-connect-unknown-proto-error'Libravatar Junio C Hamano1-1/+1
* tk/typofix-connect-unknown-proto-error: connect: fix typo in result string of prot_name()
2015-10-14Merge branch 'jk/notes-dwim-doc'Libravatar 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-12git-multimail: update to release 1.2.0Libravatar Matthieu Moy9-226/+1218
The changes are described in CHANGES. Contributions-by: Matthieu Moy <Matthieu.Moy@imag.fr> Contributions-by: Elijah Newren <newren@palantir.com> Contributions-by: Edward d'Auvergne <edward@nmr-relax.com> Contributions-by: Vadim Zeitlin <vadim@zeitlins.org> Contributions-by: Paul Sokolovsky <paul.sokolovsky@linaro.org> Contributions-by: Michael Haggerty <mhagger@alum.mit.edu> Contributions-by: Elijah Newren <newren@gmail.com> Contributions-by: Richard Hansen <rhansen@rhansen.org> Contributions-by: Job Snijders <job@instituut.net> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-07Second batch for 2.7Libravatar Junio C Hamano1-0/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-07Merge branch 'ls/p4-path-encoding'Libravatar Junio C Hamano3-0/+75
"git p4" learned to reencode the pathname it uses to communicate with the p4 depot with a new option. * ls/p4-path-encoding: git-p4: use replacement character for non UTF-8 characters in paths git-p4: improve path encoding verbose output git-p4: add config git-p4.pathEncoding
2015-10-07Merge branch 'gb/filter-branch-progress'Libravatar Junio C Hamano1-1/+31
Give progress meter to "git filter-branch". * gb/filter-branch-progress: filter-branch: make report-progress more readable filter-branch: add passed/remaining seconds on progress
2015-10-07Merge branch 'nd/ignore-then-not-ignore'Libravatar Junio C Hamano3-10/+127
Allow a later "!/abc/def" to override an earlier "/abc" that appears in the same .gitignore file to make it easier to express "everything in /abc directory is ignored, except for ...". * nd/ignore-then-not-ignore: dir.c: don't exclude whole dir prematurely if neg pattern may match dir.c: make last_exclude_matching_from_list() run til the end
2015-10-07Merge branch 'ti/glibc-stdio-mutex-from-signal-handler'Libravatar 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-05Start cycle toward 2.7Libravatar Junio C Hamano3-2/+111
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-05Sync with 2.6.1Libravatar Junio C Hamano31-32/+508
2015-10-05Merge branch 'mm/keyid-docs'Libravatar 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-05Merge branch 'bb/remote-get-url'Libravatar Junio C Hamano3-0/+106
"git remote" learned "get-url" subcommand to show the URL for a given remote name used for fetching and pushing. * bb/remote-get-url: remote: add get-url subcommand
2015-10-05Merge branch 'jk/blame-first-parent'Libravatar 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-05Merge branch 'jw/make-arflags-customizable'Libravatar 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-05Merge branch 'jk/rebase-no-autostash'Libravatar Junio C Hamano3-2/+16
There was no way to defeat a configured rebase.autostash variable from the command line, as "git rebase --no-autostash" was missing. * jk/rebase-no-autostash: Documentation/git-rebase: fix --no-autostash formatting rebase: support --no-autostash
2015-10-05Merge branch 'jk/make-findstring-makeflags-fix'Libravatar 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-05Merge branch 'sb/submodule-helper'Libravatar Junio C Hamano6-149/+301
The infrastructure to rewrite "git submodule" in C is being built incrementally. Let's polish these early parts well enough and make them graduate to 'next' and 'master', so that the more involved follow-up can start cooking on a solid ground. * sb/submodule-helper: submodule: rewrite `module_clone` shell function in C submodule: rewrite `module_name` shell function in C submodule: rewrite `module_list` shell function in C
2015-10-05Merge branch 'kn/for-each-tag'Libravatar Junio C Hamano13-379/+746
The "ref-filter" code was taught about many parts of what "tag -l" does and then "tag -l" is being reimplemented in terms of "ref-filter". * kn/for-each-tag: tag.c: implement '--merged' and '--no-merged' options tag.c: implement '--format' option tag.c: use 'ref-filter' APIs tag.c: use 'ref-filter' data structures ref-filter: add option to match literal pattern ref-filter: add support to sort by version ref-filter: add support for %(contents:lines=X) ref-filter: add option to filter out tags, branches and remotes ref-filter: implement an `align` atom ref-filter: introduce match_atom_name() ref-filter: introduce handler function for each atom utf8: add function to align a string into given strbuf ref-filter: introduce ref_formatting_state and ref_formatting_stack ref-filter: move `struct atom_value` to ref-filter.c strtoul_ui: reject negative values
2015-10-05Merge branch 'jk/test-lint-forbid-when-finished-in-subshell'Libravatar Junio C Hamano4-16/+31
Because "test_when_finished" in our test framework queues the clean-up tasks to be done in a shell variable, it should not be used inside a subshell. Add a mechanism to allow 'bash' to catch such uses, and fix the ones that were found. * jk/test-lint-forbid-when-finished-in-subshell: test-lib-functions: detect test_when_finished in subshell t7800: don't use test_config in a subshell test-lib-functions: support "test_config -C <dir> ..." t5801: don't use test_when_finished in a subshell t7610: don't use test_config in a subshell
2015-10-05Merge branch 'jk/interpret-trailers-outside-a-repository'Libravatar Junio C Hamano1-1/+1
Allow "git interpret-trailers" to run outside of a Git repository. * jk/interpret-trailers-outside-a-repository: interpret-trailers: allow running outside a repository
2015-10-05Merge branch 'as/subtree-with-spaces'Libravatar Junio C Hamano2-74/+124
Update "git subtree" (in contrib/) so that it can take whitespaces in the pathnames, not only in the in-tree pathname but the name of the directory that the repository is in. * as/subtree-with-spaces: contrib/subtree: respect spaces in a repository path t7900-subtree: test the "space in a subdirectory name" case
2015-10-05Merge branch 'jk/connect-clear-env'Libravatar Junio C Hamano2-11/+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-05Merge branch 'jk/date-local'Libravatar Junio C Hamano10-114/+166
"git log --date=local" used to only show the normal (default) format in the local timezone. The command learned to take 'local' as an instruction to use the local timezone with other formats, e.g. "git show --date=rfc-local". * jk/date-local: t6300: add tests for "-local" date formats t6300: make UTC and local dates different date: make "local" orthogonal to date format date: check for "local" before anything else t6300: add test for "raw" date format t6300: introduce test_date() helper fast-import: switch crash-report date to iso8601 Documentation/rev-list: don't list date formats Documentation/git-for-each-ref: don't list date formats Documentation/config: don't list date formats Documentation/blame-options: don't list date formats
2015-10-05Merge branch 'dt/refs-bisection'Libravatar Junio C Hamano6-33/+313
Move the refs used during a "git bisect" session to per-worktree hierarchy refs/worktree/* so that independent bisect sessions can be done in different worktrees. * dt/refs-bisection: refs: make refs/bisect/* per-worktree path: optimize common dir checking refs: clean up common_list
2015-10-05Merge branch 'nk/stash-show-config'Libravatar Junio C Hamano3-1/+31
Users who are too busy to type three extra keystrokes to ask for "git stash show -p" can now set stash.showPatch configuration varible to true to always see the actual patch, not just the list of paths affected with feel for the extent of damage via diffstat. * nk/stash-show-config: stash: allow "stash show" diff output configurable
2015-10-05Merge branch 'jk/async-pkt-line'Libravatar Junio C Hamano3-2/+23
The debugging infrastructure for pkt-line based communication has been improved to mark the side-band communication specifically. * jk/async-pkt-line: pkt-line: show packets in async processes as "sideband" run-command: provide in_async query function
2015-10-05Merge branch 'jh/quiltimport-explicit-series-file'Libravatar Junio C Hamano2-4/+23
"quiltimport" allows to specify the series file by honoring the $QUILT_SERIES environment and also --series command line option. * jh/quiltimport-explicit-series-file: git-quiltimport: add commandline option --series <file>
2015-10-05Merge branch 'ld/p4-import-labels'Libravatar Junio C Hamano2-8/+62
Correct "git p4 --detect-labels" so that it does not fail to create a tag that points at a commit that is also being imported. * ld/p4-import-labels: git-p4: fix P4 label import for unprocessed commits git-p4: do not terminate creating tag for unknown commit git-p4: failing test for ignoring invalid p4 labels
2015-10-05Merge branch 'ad/bisect-terms'Libravatar Junio C Hamano4-16/+350
The use of 'good/bad' in "git bisect" made it confusing to use when hunting for a state change that is not a regression (e.g. bugfix). The command learned 'old/new' and then allows the end user to say e.g. "bisect start --term-old=fast --term=new=slow" to find a performance regression. Michael's idea to make 'good/bad' more intelligent does have certain attractiveness ($gname/272867), and makes some of the work on this topic a moot point. * ad/bisect-terms: bisect: allow setting any user-specified in 'git bisect start' bisect: add 'git bisect terms' to view the current terms bisect: add the terms old/new bisect: sanity check on terms
2015-10-05Merge branch 'jc/rerere'Libravatar Junio C Hamano3-154/+417
Code clean-up and minor fixes. * jc/rerere: (21 commits) rerere: un-nest merge() further rerere: use "struct rerere_id" instead of "char *" for conflict ID rerere: call conflict-ids IDs rerere: further clarify do_rerere_one_path() rerere: further de-dent do_plain_rerere() rerere: refactor "replay" part of do_plain_rerere() rerere: explain the remainder rerere: explain "rerere forget" codepath rerere: explain the primary codepath rerere: explain MERGE_RR management helpers rerere: fix benign off-by-one non-bug and clarify code rerere: explain the rerere I/O abstraction rerere: do not leak mmfile[] for a path with multiple stage #1 entries rerere: stop looping unnecessarily rerere: drop want_sp parameter from is_cmarker() rerere: report autoupdated paths only after actually updating them rerere: write out each record of MERGE_RR in one go rerere: lift PATH_MAX limitation rerere: plug conflict ID leaks rerere: handle conflicts with multiple stage #1 entries ...
2015-10-05Merge branch 'kn/for-each-tag-branch'Libravatar Junio C Hamano9-51/+420
Some features from "git tag -l" and "git branch -l" have been made available to "git for-each-ref" so that eventually the unified implementation can be shared across all three, in a follow-up series or two. * kn/for-each-tag-branch: for-each-ref: add '--contains' option ref-filter: implement '--contains' option parse-options.h: add macros for '--contains' option parse-option: rename parse_opt_with_commit() for-each-ref: add '--merged' and '--no-merged' options ref-filter: implement '--merged' and '--no-merged' options ref-filter: add parse_opt_merge_filter() for-each-ref: add '--points-at' option ref-filter: implement '--points-at' option tag: libify parse_opt_points_at() t6302: for-each-ref tests for ref-filter APIs
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-25http: limit redirection depthLibravatar Blake Burkhart3-0/+8
By default, libcurl will follow circular http redirects forever. Let's put a cap on this so that somebody who can trigger an automated fetch of an arbitrary repository (e.g., for CI) cannot convince git to loop infinitely. The value chosen is 20, which is the same default that Firefox uses. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25http: limit redirection to protocol-whitelistLibravatar Blake Burkhart4-5/+27
Previously, libcurl would follow redirection to any protocol it was compiled for support with. This is desirable to allow redirection from HTTP to HTTPS. However, it would even successfully allow redirection from HTTP to SFTP, a protocol that git does not otherwise support at all. Furthermore git's new protocol-whitelisting could be bypassed by following a redirect within the remote helper, as it was only enforced at transport selection time. This patch limits redirects within libcurl to HTTP, HTTPS, FTP and FTPS. If there is a protocol-whitelist present, this list is limited to those also allowed by the whitelist. As redirection happens from within libcurl, it is impossible for an HTTP redirect to a protocol implemented within another remote helper. When the curl version git was compiled with is too old to support restrictions on protocol redirection, we warn the user if GIT_ALLOW_PROTOCOL restrictions were requested. This is a little inaccurate, as even without that variable in the environment, we would still restrict SFTP, etc, and we do not warn in that case. But anything else means we would literally warn every time git accesses an http remote. This commit includes a test, but it is not as robust as we would hope. It redirects an http request to ftp, and checks that curl complained about the protocol, which means that we are relying on curl's specific error message to know what happened. Ideally we would redirect to a working ftp server and confirm that we can clone without protocol restrictions, and not with them. But we do not have a portable way of providing an ftp server, nor any other protocol that curl supports (https is the closest, but we would have to deal with certificates). [jk: added test and version warning] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>