summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2017-08-23Merge branch 'jk/reflog-walk' into maintLibravatar Junio C Hamano3-12/+136
Numerous bugs in walking of reflogs via "log -g" and friends have been fixed. * jk/reflog-walk: reflog-walk: apply --since/--until to reflog dates reflog-walk: stop using fake parents rev-list: check reflog_info before showing usage get_revision_1(): replace do-while with an early return log: do not free parents when walking reflog log: clarify comment about reflog cycles revision: disallow reflog walking with revs->limited t1414: document some reflog-walk oddities
2017-08-23Merge branch 'jk/ref-filter-colors' into maintLibravatar Junio C Hamano6-72/+175
"%C(color name)" in the pretty print format always produced ANSI color escape codes, which was an early design mistake. They now honor the configuration (e.g. "color.ui = never") and also tty-ness of the output medium. * jk/ref-filter-colors: ref-filter: consult want_color() before emitting colors pretty: respect color settings for %C placeholders rev-list: pass diffopt->use_colors through to pretty-print for-each-ref: load config earlier color: check color.ui in git_default_config() ref-filter: pass ref_format struct to atom parsers ref-filter: factor out the parsing of sorting atoms ref-filter: make parse_ref_filter_atom a private function ref-filter: provide a function for parsing sort options ref-filter: move need_color_reset_at_eol into ref_format ref-filter: abstract ref format into its own struct ref-filter: simplify automatic color reset t: use test_decode_color rather than literal ANSI codes docs/for-each-ref: update pointer to color syntax check return value of verify_ref_format()
2017-08-04Merge tag 'v2.13.5' into maintLibravatar Junio C Hamano4-2/+57
2017-08-01Merge tag 'v2.12.4' into maintLibravatar Junio C Hamano4-2/+57
2017-07-31Merge branch 'jk/test-copy-bytes-fix' into maintLibravatar Junio C Hamano1-0/+1
A test fix. * jk/test-copy-bytes-fix: t: handle EOF in test_copy_bytes()
2017-07-31Merge branch 'pw/unquote-path-in-git-pm' into maintLibravatar Junio C Hamano1-0/+7
Code refactoring. * pw/unquote-path-in-git-pm: t9700: add tests for Git::unquote_path() Git::unquote_path(): throw an exception on bad path Git::unquote_path(): handle '\a' add -i: move unquote_path() to Git.pm
2017-07-31Merge branch 'jk/gc-pre-detach-under-hook' into maintLibravatar Junio C Hamano1-0/+21
We run an early part of "git gc" that deals with refs before daemonising (and not under lock) even when running a background auto-gc, which caused multiple gc processes attempting to run the early part at the same time. This is now prevented by running the early part also under the GC lock. * jk/gc-pre-detach-under-hook: gc: run pre-detach operations under lock
2017-07-31Merge branch 'tb/push-to-cygwin-unc-path' into maintLibravatar Junio C Hamano1-0/+2
On Cygwin, similar to Windows, "git push //server/share/repository" ought to mean a repository on a network share that can be accessed locally, but this did not work correctly due to stripping the double slashes at the beginning. This may need to be heavily tested before it gets unleashed to the wild, as the change is at a fairly low-level code and would affect not just the code to decide if the push destination is local. There may be unexpected fallouts in the path normalization. * tb/push-to-cygwin-unc-path: cygwin: allow pushing to UNC paths
2017-07-30Merge tag 'v2.11.3' into maint-2.12Libravatar Junio C Hamano3-0/+51
Git 2.11.3
2017-07-30Merge tag 'v2.10.4' into maint-2.11Libravatar Junio C Hamano3-0/+51
Git 2.10.4
2017-07-30Merge tag 'v2.9.5' into maint-2.10Libravatar Junio C Hamano3-0/+51
Git 2.9.5
2017-07-30Merge tag 'v2.8.6' into maint-2.9Libravatar Junio C Hamano3-0/+51
Git 2.8.6
2017-07-30Merge tag 'v2.7.6' into maint-2.8Libravatar Junio C Hamano3-0/+51
Git 2.7.6
2017-07-28connect: reject paths that look like command line optionsLibravatar Jeff King2-0/+37
If we get a repo path like "-repo.git", we may try to invoke "git-upload-pack -repo.git". This is going to fail, since upload-pack will interpret it as a set of bogus options. But let's reject this before we even run the sub-program, since we would not want to allow any mischief with repo names that actually are real command-line options. You can still ask for such a path via git-daemon, but there's no security problem there, because git-daemon enters the repo itself and then passes "." on the command line. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28connect: reject dashed arguments for proxy commandsLibravatar Jeff King1-0/+5
If you have a GIT_PROXY_COMMAND configured, we will run it with the host/port on the command-line. If a URL contains a mischievous host like "--foo", we don't know how the proxy command may handle it. It's likely to break, but it may also do something dangerous and unwanted (technically it could even do something useful, but that seems unlikely). We should err on the side of caution and reject this before we even run the command. The hostname check matches the one we do in a similar circumstance for ssh. The port check is not present for ssh, but there it's not necessary because the syntax is "-p <port>", and there's no ambiguity on the parsing side. It's not clear whether you can actually get a negative port to the proxy here or not. Doing: git fetch git://remote:-1234/repo.git keeps the "-1234" as part of the hostname, with the default port of 9418. But it's a good idea to keep this check close to the point of running the command to make it clear that there's no way to circumvent it (and at worst it serves as a belt-and-suspenders check). Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28t5813: add test for hostname starting with dashLibravatar Jeff King1-0/+9
Per the explanation in the previous patch, this should be (and is) rejected. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28t/lib-proto-disable: restore protocol.allow after config testsLibravatar Jeff King1-2/+6
The tests for protocol.allow actually set that variable in the on-disk config, run a series of tests, and then never clean up after themselves. This means that whatever tests we run after have protocol.allow=never, which may influence their results. In most cases we either exit after running these tests, or do another round of test_proto(). In the latter case, this happens to work because: 1. Tests of the GIT_ALLOW_PROTOCOL environment variable override the config. 2. Tests of the specific config "protocol.foo.allow" override the protocol.allow config. 3. The next round of protocol.allow tests start off by setting the config to a known value. However, it's a land-mine waiting to trap somebody adding new tests to one of the t581x test scripts. Let's make sure we clean up after ourselves. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-21Merge branch 'js/alias-case-sensitivity' into maintLibravatar Junio C Hamano1-0/+7
A recent update broke an alias that contained an uppercase letter. * js/alias-case-sensitivity: alias: compare alias name *case-insensitively* t1300: demonstrate that CamelCased aliases regressed
2017-07-20Merge branch 'mt/p4-parse-G-output'Libravatar Junio C Hamano1-0/+103
Use "p4 -G" to make "p4 changes" output more Python-friendly to parse. * mt/p4-parse-G-output: git-p4: filter for {'code':'info'} in p4CmdList git-p4: parse marshal output "p4 -G" in p4 changes git-p4: git-p4 tests with p4 triggers
2017-07-20Merge branch 'jk/test-copy-bytes-fix'Libravatar Junio C Hamano1-0/+1
A test fix. * jk/test-copy-bytes-fix: t: handle EOF in test_copy_bytes()
2017-07-20Merge branch 'js/alias-case-sensitivity'Libravatar Junio C Hamano1-0/+7
A recent update broke an alias that contained an uppercase letter. * js/alias-case-sensitivity: alias: compare alias name *case-insensitively* t1300: demonstrate that CamelCased aliases regressed
2017-07-18Merge branch 'jk/gc-pre-detach-under-hook'Libravatar Junio C Hamano1-0/+21
We run an early part of "git gc" that deals with refs before daemonising (and not under lock) even when running a background auto-gc, which caused multiple gc processes attempting to run the early part at the same time. This is now prevented by running the early part also under the GC lock. * jk/gc-pre-detach-under-hook: gc: run pre-detach operations under lock
2017-07-18Merge branch 'tb/push-to-cygwin-unc-path'Libravatar Junio C Hamano1-0/+2
On Cygwin, similar to Windows, "git push //server/share/repository" ought to mean a repository on a network share that can be accessed locally, but this did not work correctly due to stripping the double slashes at the beginning. This may need to be heavily tested before it gets unleashed to the wild, as the change is at a fairly low-level code and would affect not just the code to decide if the push destination is local. There may be unexpected fallouts in the path normalization. * tb/push-to-cygwin-unc-path: cygwin: allow pushing to UNC paths
2017-07-17t: handle EOF in test_copy_bytes()Libravatar Jeff King1-0/+1
The test_copy_bytes() function claims to read up to N bytes, or until it gets EOF. But we never handle EOF in our loop, and a short input will cause perl to go into an infinite loop of read() getting zero bytes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-17alias: compare alias name *case-insensitively*Libravatar Johannes Schindelin1-1/+1
It is totally legitimate to add CamelCased aliases, but due to the way config keys are compared, the case does not matter. Therefore, we must compare the alias name insensitively to the config keys. This fixes a regression introduced by a9bcf6586d1 (alias: use the early config machinery to expand aliases, 2017-06-14). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-17t1300: demonstrate that CamelCased aliases regressedLibravatar Johannes Schindelin1-0/+7
It is totally legitimate to add CamelCased aliases, but due to the way config keys are compared, the case does not matter. Except that now it does: the alias name is expected to be all lower-case. This is a regression introduced by a9bcf6586d1 (alias: use the early config machinery to expand aliases, 2017-06-14). Noticed by Alejandro Pauly, diagnosed by Kevin Willford. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13Merge branch 'jk/build-with-asan'Libravatar Junio C Hamano1-3/+8
The build procedure has been improved to allow building and testing Git with address sanitizer more easily. * jk/build-with-asan: Makefile: disable unaligned loads with UBSan Makefile: turn off -fomit-frame-pointer with sanitizers Makefile: add helper for compiling with -fsanitize test-lib: turn on ASan abort_on_error by default test-lib: set ASAN_OPTIONS variable before we run git
2017-07-13Merge branch 'sb/pull-rebase-submodule'Libravatar Junio C Hamano1-0/+58
"git pull --rebase --recurse-submodules" learns to rebase the branch in the submodules to an updated base. * sb/pull-rebase-submodule: builtin/fetch cleanup: always set default value for submodule recursing pull: optionally rebase submodules (remote submodule changes only) builtin/fetch: parse recurse-submodules-default at default options parsing builtin/fetch: factor submodule recurse parsing out to submodule config
2017-07-13Merge branch 'sb/hashmap-customize-comparison'Libravatar Junio C Hamano1-7/+12
Update the hashmap API so that data to customize the behaviour of the comparison function can be specified at the time a hashmap is initialized. * sb/hashmap-customize-comparison: hashmap: migrate documentation from Documentation/technical into header patch-ids.c: use hashmap correctly hashmap.h: compare function has access to a data field
2017-07-13ref-filter: consult want_color() before emitting colorsLibravatar Jeff King3-11/+82
When color placeholders like %(color:red) are used in a ref-filter format, we unconditionally output the colors, even if the user has asked us for no colors. This usually isn't a problem when the user is constructing a --format on the command line, but it means we may do the wrong thing when the format is fed from a script or alias. For example: $ git config alias.b 'branch --format=%(color:green)%(refname)' $ git b --no-color should probably omit the green color. Likewise, running: $ git b >branches should probably also omit the color, just as we would for all baked-in coloring (and as we recently started to do for user-specified colors in --pretty formats). This commit makes both of those cases work by teaching the ref-filter code to consult want_color() before outputting any color. The color flag in ref_format defaults to "-1", which means we'll consult color.ui, which in turn defaults to the usual isatty() check on stdout. However, callers like git-branch which support their own color config (and command-line options) can override that. The new tests independently cover all three of the callers of ref-filter (for-each-ref, tag, and branch). Even though these seem redundant, it confirms that we've correctly plumbed through all of the necessary config to make colors work by default. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13pretty: respect color settings for %C placeholdersLibravatar Jeff King1-34/+50
The color placeholders have traditionally been unconditional, showing colors even when git is not otherwise configured to do so. This was not so bad for their original use, which was on the command-line (and the user could decide at that moment whether to add colors or not). But these days we have configured formats via pretty.*, and those should operate correctly in multiple contexts. In 3082517 (log --format: teach %C(auto,black) to respect color config, 2012-12-17), we gave an extended placeholder that could be used to accomplish this. But it's rather clunky to use, because you have to specify it individually for each color (and their matching resets) in the format. We shied away from just switching the default to auto, because it is technically breaking backwards compatibility. However, there's not really a use case for unconditional colors. The most plausible reason you would want them is to redirect "git log" output to a file. But there, the right answer is --color=always, as it does the right thing both with custom user-format colors and git-generated colors. So let's switch to the more useful default. In the off-chance that somebody really does find a use for unconditional colors without wanting to enable the rest of git's colors, we provide a new %C(always,...) to enable the old behavior. And we can remind them of --color=always in the documentation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13rev-list: pass diffopt->use_colors through to pretty-printLibravatar Jeff King1-0/+11
When rev-list pretty-prints a commit, it creates a new pretty_print_context and copies items from the rev_info struct. We don't currently copy the "use_color" field, though. Nobody seems to have noticed because the only part of pretty.c that cares is the %C(auto,...) placeholder, and presumably not many people use that with the rev-list plumbing (as opposed to with git-log). It will become more noticeable in a future patch, though, when we start treating all user-format colors as auto-colors (in which case it would become impossible to format colors with rev-list, even with --color=always). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13t: use test_decode_color rather than literal ANSI codesLibravatar Jeff King4-39/+44
When we put literal ANSI terminal codes into our test scripts, it makes diffs on those scripts hard to read (the colors may be indistinguishable from diff coloring, or in the case of a reset, may not be visible at all). Some scripts get around this by including human-readable names and converting to literal codes with a git-config hack. This makes the actual code diffs look OK, but test_cmp output suffers from the same problem. Let's use test_decode_color instead, which turns the codes into obvious text tags. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13git-p4: filter for {'code':'info'} in p4CmdListLibravatar Miguel Torroja1-2/+2
The function p4CmdList accepts a new argument: skip_info. When set to True it ignores any 'code':'info' entry (skip_info=False by default). That allows us to fix some of the tests in t9831-git-p4-triggers.sh known to be broken with verobse p4 triggers Signed-off-by: Miguel Torroja <miguel.torroja@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13git-p4: parse marshal output "p4 -G" in p4 changesLibravatar Miguel Torroja1-1/+1
The option -G of p4 (python marshal output) gives more context about the data being output. That's useful when using the command "change -o" as we can distinguish between warning/error line and real change description. This fixes the case where a p4 trigger for "p4 change" is set and the command git-p4 submit is run. Signed-off-by: Miguel Torroja <miguel.torroja@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13git-p4: git-p4 tests with p4 triggersLibravatar Miguel Torroja1-0/+103
Some p4 triggers in the server side generate some warnings when executed. Unfortunately those messages are mixed with the output of p4 commands. A few git-p4 commands don't expect extra messages or output lines and may fail with verbose triggers. New tests added are known to be broken. Signed-off-by: Miguel Torroja <miguel.torroja@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-12Merge branch 'kn/ref-filter-branch-list' into maintLibravatar Junio C Hamano1-0/+44
The rewrite of "git branch --list" using for-each-ref's internals that happened in v2.13 regressed its handling of color.branch.local; this has been fixed. * kn/ref-filter-branch-list: ref-filter.c: drop return from void function branch: set remote color in ref-filter branch immediately branch: use BRANCH_COLOR_LOCAL in ref-filter format branch: only perform HEAD check for local branches
2017-07-12Merge branch 'jk/reflog-walk-maint' into maintLibravatar Junio C Hamano2-0/+21
After "git branch --move" of the currently checked out branch, the code to walk the reflog of HEAD via "log -g" and friends incorrectly stopped at the reflog entry that records the renaming of the branch. * jk/reflog-walk-maint: reflog-walk: include all fields when freeing complete_reflogs reflog-walk: don't free reflogs added to cache reflog-walk: duplicate strings in complete_reflogs list reflog-walk: skip over double-null oid due to HEAD rename
2017-07-12Merge branch 'kn/ref-filter-branch-list'Libravatar Junio C Hamano1-0/+44
The rewrite of "git branch --list" using for-each-ref's internals that happened in v2.13 regressed its handling of color.branch.local; this has been fixed. * kn/ref-filter-branch-list: ref-filter.c: drop return from void function branch: set remote color in ref-filter branch immediately branch: use BRANCH_COLOR_LOCAL in ref-filter format branch: only perform HEAD check for local branches
2017-07-12gc: run pre-detach operations under lockLibravatar Jeff King1-0/+21
We normally try to avoid having two auto-gc operations run at the same time, because it wastes resources. This was done long ago in 64a99eb47 (gc: reject if another gc is running, unless --force is given, 2013-08-08). When we do a detached auto-gc, we run the ref-related commands _before_ detaching, to avoid confusing lock contention. This was done by 62aad1849 (gc --auto: do not lock refs in the background, 2014-05-25). These two features do not interact well. The pre-detach operations are run before we check the gc.pid lock, meaning that on a busy repository we may run many of them concurrently. Ideally we'd take the lock before spawning any operations, and hold it for the duration of the program. This is tricky, though, with the way the pid-file interacts with the daemonize() process. Other processes will check that the pid recorded in the pid-file still exists. But detaching causes us to fork and continue running under a new pid. So if we take the lock before detaching, the pid-file will have a bogus pid in it. We'd have to go back and update it with the new pid after detaching. We'd also have to play some tricks with the tempfile subsystem to tweak the "owner" field, so that the parent process does not clean it up on exit, but the child process does. Instead, we can do something a bit simpler: take the lock only for the duration of the pre-detach work, then detach, then take it again for the post-detach work. Technically, this means that the post-detach lock could lose to another process doing pre-detach work. But in the long run this works out. That second process would then follow-up by doing post-detach work. Unless it was in turn blocked by a third process doing pre-detach work, and so on. This could in theory go on indefinitely, as the pre-detach work does not repack, and so need_to_gc() will continue to trigger. But in each round we are racing between the pre- and post-detach locks. Eventually, one of the post-detach locks will win the race and complete the full gc. So in the worst case, we may racily repeat the pre-detach work, but we would never do so simultaneously (it would happen via a sequence of serialized race-wins). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-10Merge branch 'js/fsck-name-object' into maintLibravatar Junio C Hamano1-1/+1
Test fix. * js/fsck-name-object: t1450: use egrep for regexp "alternation"
2017-07-10Merge branch 'js/t5534-rev-parse-gives-multi-line-output-fix' into maintLibravatar Junio C Hamano1-4/+10
A few tests that tried to verify the contents of push certificates did not use 'git rev-parse' to formulate the line to look for in the certificate correctly. * js/t5534-rev-parse-gives-multi-line-output-fix: t5534: fix misleading grep invocation
2017-07-10Merge branch 'cc/shared-index-permfix' into maintLibravatar Junio C Hamano3-11/+42
The split index code did not honor core.sharedrepository setting correctly. * cc/shared-index-permfix: t1700: make sure split-index respects core.sharedrepository t1301: move modebits() to test-lib-functions.sh read-cache: use shared perms when writing shared index
2017-07-10Merge branch 'ks/t7508-indent-fix' into maintLibravatar Junio C Hamano1-1/+1
Cosmetic update to a test. * ks/t7508-indent-fix: t7508: fix a broken indentation
2017-07-10Merge branch 'sb/t4005-modernize' into maintLibravatar Junio C Hamano1-52/+43
Test clean-up. * sb/t4005-modernize: t4005: modernize style and drop hard coded sha1
2017-07-10Merge branch 'rs/apply-validate-input' into maintLibravatar Junio C Hamano3-1/+57
Tighten error checks for invalid "git apply" input. * rs/apply-validate-input: apply: check git diffs for mutually exclusive header lines apply: check git diffs for invalid file modes apply: check git diffs for missing old filenames
2017-07-10Merge branch 'pw/rebase-i-regression-fix-tests' into maintLibravatar Junio C Hamano2-5/+140
Fix a recent regression to "git rebase -i" and add tests that would have caught it and others. * pw/rebase-i-regression-fix-tests: t3420: fix under GETTEXT_POISON build rebase: add more regression tests for console output rebase: add regression tests for console output rebase -i: add test for reflog message sequencer: print autostash messages to stderr
2017-07-10Merge branch 'jk/add-p-commentchar-fix' into maintLibravatar Junio C Hamano1-0/+8
"git add -p" were updated in 2.12 timeframe to cope with custom core.commentchar but the implementation was buggy and a metacharacter like $ and * did not work. * jk/add-p-commentchar-fix: add--interactive: quote commentChar regex add--interactive: handle EOF in prompt_yesno
2017-07-10Merge branch 'js/alias-early-config' into maintLibravatar Junio C Hamano3-1/+20
The code to pick up and execute command alias definition from the configuration used to switch to the top of the working tree and then come back when the expanded alias was executed, which was unnecessarilyl complex. Attempt to simplify the logic by using the early-config mechanism that does not chdir around. * js/alias-early-config: alias: use the early config machinery to expand aliases t7006: demonstrate a problem with aliases in subdirectories t1308: relax the test verifying that empty alias values are disallowed help: use early config when autocorrecting aliases config: report correct line number upon error discover_git_directory(): avoid setting invalid git_dir
2017-07-10Merge branch 'jk/reflog-walk-maint'Libravatar Junio C Hamano2-0/+21
After "git branch --move" of the currently checked out branch, the code to walk the reflog of HEAD via "log -g" and friends incorrectly stopped at the reflog entry that records the renaming of the branch. * jk/reflog-walk-maint: reflog-walk: include all fields when freeing complete_reflogs reflog-walk: don't free reflogs added to cache reflog-walk: duplicate strings in complete_reflogs list reflog-walk: skip over double-null oid due to HEAD rename