summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2018-11-19Merge branch 'nd/format-patch-cover-letter-stat-width'Libravatar Junio C Hamano1-15/+33
"git format-patch --stat=<width>" can be used to specify the width used by the diffstat (shown in the cover letter). * nd/format-patch-cover-letter-stat-width: format-patch: respect --stat in cover letter's diffstat
2018-11-19Merge branch 'ab/dynamic-gettext-poison'Libravatar Junio C Hamano9-19/+40
Our testing framework uses a special i18n "poisoned localization" feature to find messages that ought to stay constant but are incorrectly marked to be translated. This feature has been made into a runtime option (it used to be a compile-time option). * ab/dynamic-gettext-poison: Makefile: ease dynamic-gettext-poison transition i18n: make GETTEXT_POISON a runtime option
2018-11-18Merge branch 'jk/close-duped-fd-before-unlock-for-bundle'Libravatar Junio C Hamano1-0/+6
When "git bundle" aborts due to an empty commit ranges (i.e. resulting in an empty pack), it left a file descriptor to an lockfile open, which resulted in leftover lockfile on Windows where you cannot remove a file with an open file descriptor. This has been corrected. * jk/close-duped-fd-before-unlock-for-bundle: bundle: dup() output descriptor closer to point-of-use
2018-11-18Merge branch 'ab/rebase-in-c-escape-hatch'Libravatar Junio C Hamano1-0/+4
The recently merged "rebase in C" has an escape hatch to use the scripted version when necessary, but it hasn't been documented, which has been corrected. * ab/rebase-in-c-escape-hatch: tests: add a special setup where rebase.useBuiltin is off rebase doc: document rebase.useBuiltin
2018-11-18Merge branch 'js/rebase-am-options'Libravatar Junio C Hamano1-0/+7
The way "git rebase" parses and forwards the command line options meant for underlying "git am" has been revamped, which fixed for options with parameters that were not passed correctly. * js/rebase-am-options: rebase: validate -C<n> and --whitespace=<mode> parameters early rebase: really just passthru the `git am` options
2018-11-18Merge branch 'sg/ref-filter-wo-repository'Libravatar Junio C Hamano1-0/+6
"git ls-remote --sort=<thing>" can feed an object that is not yet available into the comparison machinery and segfault, which has been corrected to check such a request upfront and reject it. * sg/ref-filter-wo-repository: ref-filter: don't look for objects when outside of a repository
2018-11-18Merge branch 'ag/p3400-force-checkout'Libravatar Junio C Hamano1-5/+5
Perf test tweak. * ag/p3400-force-checkout: p3400: replace calls to `git checkout -b' by `git checkout -B'
2018-11-18Merge branch 'js/rebase-r-and-merge-head'Libravatar Junio C Hamano1-0/+16
Bugfix for the recently graduated "git rebase --rebase-merges". * js/rebase-r-and-merge-head: status: rebase and merge can be in progress at the same time built-in rebase --skip/--abort: clean up stale .git/<name> files rebase -i: include MERGE_HEAD into files to clean up rebase -r: do not write MERGE_HEAD unless needed rebase -r: demonstrate bug with conflicting merges
2018-11-18Merge branch 'js/apply-recount-allow-noop'Libravatar Junio C Hamano1-0/+12
When editing a patch in a "git add -i" session, a hunk could be made to no-op. The "git apply" program used to reject a patch with such a no-op hunk to catch user mistakes, but it is now updated to explicitly allow a no-op hunk in an edited patch. * js/apply-recount-allow-noop: apply --recount: allow "no-op hunks"
2018-11-18Merge branch 'ra/rev-parse-exclude-glob'Libravatar Junio C Hamano1-3/+57
"rev-parse --exclude=<pattern> --branches=<pattern>" etc. did not quite work, which has been corrected. * ra/rev-parse-exclude-glob: refs: fix some exclude patterns being ignored refs: show --exclude failure with --branches/tags/remotes=glob
2018-11-18Merge branch 'js/rebase-autostash-detach-fix'Libravatar Junio C Hamano1-0/+8
"git rebase --autostash" did not correctly re-attach the HEAD at times. * js/rebase-autostash-detach-fix: built-in rebase --autostash: leave the current branch alone if possible built-in rebase: demonstrate regression with --autostash
2018-11-18Merge branch 'ab/range-diff-no-patch'Libravatar Junio C Hamano1-0/+30
The "--no-patch" option, which can be used to get a high-level overview without the actual line-by-line patch difference shown, of the "range-diff" command was earlier broken, which has been corrected. * ab/range-diff-no-patch: range-diff: make diff option behavior (e.g. --stat) consistent range-diff: fix regression in passing along diff options range-diff doc: add a section about output stability
2018-11-18Merge branch 'jk/verify-sig-merge-into-void'Libravatar Junio C Hamano2-0/+14
"git merge" and "git pull" that merges into an unborn branch used to completely ignore "--verify-signatures", which has been corrected. * jk/verify-sig-merge-into-void: pull: handle --verify-signatures for unborn branch merge: handle --verify-signatures for unborn branch merge: extract verify_merge_signature() helper
2018-11-18Merge branch 'jk/unused-parameter-fixes'Libravatar Junio C Hamano2-23/+1
Various functions have been audited for "-Wunused-parameter" warnings and bugs in them got fixed. * jk/unused-parameter-fixes: midx: double-check large object write loop assert NOARG/NONEG behavior of parse-options callbacks parse-options: drop OPT_DATE() apply: return -1 from option callback instead of calling exit(1) cat-file: report an error on multiple --batch options tag: mark "--message" option with NONEG show-branch: mark --reflog option as NONEG format-patch: mark "--no-numbered" option with NONEG status: mark --find-renames option with NONEG cat-file: mark batch options with NONEG pack-objects: mark index-version option as NONEG ls-files: mark exclude options as NONEG am: handle --no-patch-format option apply: mark include/exclude options as NONEG
2018-11-18Merge branch 'mg/gpg-fingerprint-test'Libravatar Junio C Hamano2-14/+70
Add a few tests for a topic already in 'master'. * mg/gpg-fingerprint-test: t/t7510-signed-commit.sh: add signing subkey to Eris Discordia key t/t7510-signed-commit.sh: Add %GP to custom format checks
2018-11-18Merge branch 'ds/reachable-topo-order'Libravatar Junio C Hamano4-21/+160
The revision walker machinery learned to take advantage of the commit generation numbers stored in the commit-graph file. * ds/reachable-topo-order: t6012: make rev-list tests more interesting revision.c: generation-based topo-order algorithm commit/revisions: bookkeeping before refactoring revision.c: begin refactoring --topo-order logic test-reach: add rev-list tests test-reach: add run_three_modes method prio-queue: add 'peek' operation
2018-11-17bundle: dup() output descriptor closer to point-of-useLibravatar Jeff King1-0/+6
When writing a bundle to a file, the bundle code actually creates "your.bundle.lock" using our lockfile interface. We feed that output descriptor to a child git-pack-objects via run-command, which has the quirk that it closes the output descriptor in the parent. To avoid confusing the lockfile code (which still thinks the descriptor is valid), we dup() it, and operate on the duplicate. However, this has a confusing side effect: after the dup() but before we call pack-objects, we have _two_ descriptors open to the lockfile. If we call die() during that time, the lockfile code will try to clean up the partially-written file. It knows to close() the file before unlinking, since on some platforms (i.e., Windows) the open file would block the deletion. But it doesn't know about the duplicate descriptor. On Windows, triggering an error at the right part of the code will result in the cleanup failing and the lockfile being left in the filesystem. We can solve this by moving the dup() much closer to start_command(), shrinking the window in which we have the second descriptor open. It's easy to place this in such a way that no die() is possible. We could still die due to a signal in the exact wrong moment, but we already tolerate races there (e.g., a signal could come before we manage to put the file on the cleanup list in the first place). As a bonus, this shields create_bundle() itself from the duplicate-fd trick, and we can simplify its error handling (note that the lock rollback now happens unconditionally, but that's OK; it's a noop if we didn't open the lock in the first place). The included test uses an empty bundle to cause a failure at the right spot in the code, because that's easy to trigger (the other likely errors are write() problems like ENOSPC). Note that it would already pass on non-Windows systems (because they are happy to unlink an already-open file). Based-on-a-patch-by: Gaël Lhez <gael.lhez@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Tested-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16tests: add a special setup where rebase.useBuiltin is offLibravatar Ævar Arnfjörð Bjarmason1-0/+4
Add a GIT_TEST_REBASE_USE_BUILTIN=false test mode which is equivalent to running with rebase.useBuiltin=false. This is needed to spot that we're not introducing any regressions in the legacy rebase version while we're carrying both it and the new builtin version. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16ref-filter: don't look for objects when outside of a repositoryLibravatar SZEDER Gábor1-0/+6
The command 'git ls-remote --sort=authordate <remote>' segfaults when run outside of a repository, ever since the introduction of its '--sort' option in 1fb20dfd8e (ls-remote: create '--sort' option, 2018-04-09). While in general the 'git ls-remote' command can be run outside of a repository just fine, its '--sort=<key>' option with certain keys does require access to the referenced objects. This sorting is implemented using the generic ref-filter sorting facility, which already handles missing objects gracefully with the appropriate 'missing object deadbeef for HEAD' message. However, being generic means that it checks replace refs while trying to retrieve an object, and while doing so it accesses the 'git_replace_ref_base' variable, which has not been initialized and is still a NULL pointer when outside of a repository, thus causing the segfault. Make ref-filter more careful upfront while parsing the format string, and make it error out when encountering a format atom requiring object access when we are not in a repository. Also add a test to ensure that 'git ls-remote --sort' fails gracefully when executed outside of a repository. Reported-by: H.Merijn Brand <h.m.brand@xs4all.nl> Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16rebase: validate -C<n> and --whitespace=<mode> parameters earlyLibravatar Johannes Schindelin1-0/+7
It is a good idea to error out early upon seeing, say, `-Cbad`, rather than starting the rebase only to have the `--am` backend complain later. Let's do this. The only options accepting parameters which we pass through to `git am` (which may, or may not, forward them to `git apply`) are `-C` and `--whitespace`. The other options we pass through do not accept parameters, so we do not have to validate them here. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14range-diff: make diff option behavior (e.g. --stat) consistentLibravatar Ævar Arnfjörð Bjarmason1-23/+0
Make the behavior when diff options (e.g. "--stat") are passed consistent with how "diff" behaves. Before 73a834e9e2 ("range-diff: relieve callers of low-level configuration burden", 2018-07-22) running range-diff with "--stat" would produce stat output and the diff output, as opposed to how "diff" behaves where once "--stat" is specified "--patch" also needs to be provided to emit the patch output. As noted in a previous change ("range-diff doc: add a section about output stability", 2018-11-07) the "--stat" output with "range-diff" is useless at the moment. But we should behave consistently with "diff" in anticipation of such output being useful in the future, because it would make for confusing UI if "diff" and "range-diff" behaved differently when it came to how they interpret diff options. The new behavior is also consistent with the existing documentation added in ba931edd28 ("range-diff: populate the man page", 2018-08-13). See "[...]also accepts the regular diff options[...]" in git-range-diff(1). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13Merge branch 'nd/tree-walk-path-exclusion'Libravatar Junio C Hamano1-0/+17
Pathspec matching against a tree object were buggy when negative pathspec elements were involved, which has been fixed. * nd/tree-walk-path-exclusion: tree-walk.c: fix overoptimistic inclusion in :(exclude) matching
2018-11-13Merge branch 'jk/misc-unused-fixes'Libravatar Junio C Hamano2-0/+9
Assorted fixes for bugs found while auditing -Wunused-parameter warnings. * jk/misc-unused-fixes: approxidate: fix NULL dereference in date_time() pathspec: handle non-terminated strings with :(attr) approxidate: handle pending number for "specials" rev-list: handle flags for --indexed-objects
2018-11-13Merge branch 'nd/per-worktree-ref-iteration'Libravatar Junio C Hamano4-0/+131
The code to traverse objects for reachability, used to decide what objects are unreferenced and expendable, have been taught to also consider per-worktree refs of other worktrees as starting points to prevent data loss. * nd/per-worktree-ref-iteration: git-worktree.txt: correct linkgit command name reflog expire: cover reflog from all worktrees fsck: check HEAD and reflog from other worktrees fsck: move fsck_head_link() to get_default_heads() to avoid some globals revision.c: better error reporting on ref from different worktrees revision.c: correct a parameter name refs: new ref types to make per-worktree refs visible to all worktrees Add a place for (not) sharing stuff between worktrees refs.c: indent with tabs, not spaces
2018-11-13Merge branch 'al/send-email-auto-cte-fixup'Libravatar Junio C Hamano1-0/+15
"git send-email --transfer-encoding=..." in recent versions of Git sometimes produced an empty "Content-Transfer-Encoding:" header, which has been corrected. * al/send-email-auto-cte-fixup: send-email: avoid empty transfer encoding header
2018-11-13Merge branch 'ds/add-missing-tags'Libravatar Junio C Hamano2-4/+82
The history traversal used to implement the tag-following has been optimized by introducing a new helper. * ds/add-missing-tags: remote: make add_missing_tags() linear test-reach: test get_reachable_subset commit-reach: implement get_reachable_subset
2018-11-13Merge branch 'js/rebase-p-tests'Libravatar Junio C Hamano14-43/+78
In preparation to the day when we can deprecate and remove the "rebase -p", make sure we can skip and later remove tests for it. * js/rebase-p-tests: tests: optionally skip `git rebase -p` tests t3418: decouple test cases from a previous `rebase -p` test case t3404: decouple some test cases from outcomes of previous test cases
2018-11-13Merge branch 'ag/rev-parse-all-exclude-fix'Libravatar Junio C Hamano1-0/+12
"git rev-parse --exclude=* --branches --branches" (i.e. first saying "add only things that do not match '*' out of all branches" and then adding all branches, without any exclusion this time") worked as expected, but "--exclude=* --all --all" did not work the same way, which has been fixed. * ag/rev-parse-all-exclude-fix: rev-parse: clear --exclude list after 'git rev-parse --all'
2018-11-13Merge branch 'jt/tighten-fetch-proto-v2-response'Libravatar Junio C Hamano1-0/+50
"git fetch" was a bit loose in parsing resposes from the other side when talking over the protocol v2. * jt/tighten-fetch-proto-v2-response: fetch-pack: be more precise in parsing v2 response
2018-11-13Merge branch 'ao/submodule-wo-gitmodules-checked-out'Libravatar Junio C Hamano7-16/+298
The submodule support has been updated to read from the blob at HEAD:.gitmodules when the .gitmodules file is missing from the working tree. * ao/submodule-wo-gitmodules-checked-out: t/helper: add test-submodule-nested-repo-config submodule: support reading .gitmodules when it's not in the working tree submodule: add a helper to check if it is safe to write to .gitmodules t7506: clean up .gitmodules properly before setting up new scenario submodule: use the 'submodule--helper config' command submodule--helper: add a new 'config' subcommand t7411: be nicer to future tests and really clean things up t7411: merge tests 5 and 6 submodule: factor out a config_set_in_gitmodules_file_gently function submodule: add a print_config_from_gitmodules() helper
2018-11-13Merge branch 'js/mingw-utf8-env'Libravatar Junio C Hamano1-1/+1
Windows fix. * js/mingw-utf8-env: mingw: reencode environment variables on the fly (UTF-16 <-> UTF-8) t7800: fix quoting
2018-11-13Merge branch 'js/mingw-perl5lib'Libravatar Junio C Hamano1-0/+30
Windows fix. * js/mingw-perl5lib: mingw: unset PERL5LIB by default config: move Windows-specific config settings into compat/mingw.c config: allow for platform-specific core.* config settings config: rename `dummy` parameter to `cb` in git_default_config()
2018-11-13Merge branch 'ab/pack-tests-cleanup'Libravatar Junio C Hamano2-23/+28
A couple of tests used to leave the repository in a state that is deliberately corrupt, which have been corrected. * ab/pack-tests-cleanup: index-pack tests: don't leave test repo dirty at end pack-objects tests: don't leave test .git corrupt at end pack-objects test: modernize style
2018-11-13Merge branch 'ds/test-multi-pack-index'Libravatar Junio C Hamano4-2/+7
Tests for the recently introduced multi-pack index machinery. * ds/test-multi-pack-index: packfile: close multi-pack-index in close_all_packs multi-pack-index: define GIT_TEST_MULTI_PACK_INDEX midx: close multi-pack-index on repack midx: fix broken free() in close_midx()
2018-11-13Merge branch 'nd/wildmatch-double-asterisk'Libravatar Junio C Hamano1-2/+2
A pattern with '**' that does not have a slash on either side used to be an invalid one, but the code now treats such double-asterisks the same way as two normal asterisks that happen to be adjacent to each other. * nd/wildmatch-double-asterisk: wildmatch: change behavior of "foo**bar" in WM_PATHNAME mode
2018-11-13Merge branch 'nd/per-worktree-config'Libravatar Junio C Hamano3-60/+121
A fourth class of configuration files (in addition to the traditional "system wide", "per user in the $HOME directory" and "per repository in the $GIT_DIR/config") has been introduced so that different worktrees that share the same repository (hence the same $GIT_DIR/config file) can use different customization. * nd/per-worktree-config: worktree: add per-worktree config files t1300: extract and use test_cmp_config()
2018-11-13Merge branch 'jk/proto-v2-ref-prefix-fix'Libravatar Junio C Hamano1-0/+18
"git ls-remote $there foo" was broken by recent update for the protocol v2 and stopped showing refs that match 'foo' that are not refs/{heads,tags}/foo, which has been fixed. * jk/proto-v2-ref-prefix-fix: ls-remote: pass heads/tags prefixes to transport ls-remote: do not send ref prefixes for patterns
2018-11-13Merge branch 'jk/detect-truncated-zlib-input'Libravatar Junio C Hamano1-2/+21
A regression in Git 2.12 era made "git fsck" fall into an infinite loop while processing truncated loose objects. * jk/detect-truncated-zlib-input: cat-file: handle streaming failures consistently check_stream_sha1(): handle input underflow t1450: check large blob in trailing-garbage test
2018-11-13format-patch: respect --stat in cover letter's diffstatLibravatar Nguyễn Thái Ngọc Duy1-15/+33
Commit 43662b23ab (format-patch: keep cover-letter diffstat wrapped in 72 columns - 2018-01-24) uncondtionally sets stat width to 72 when generating diffstat for the cover letter, ignoring --stat from command line. But it should only do so when stat width is still default (i.e. stat_width == 0). In order to fix this, we should only set stat_width if stat_width is zero. But it will never be. Commit 071dd0ba43 (format-patch: reduce patch diffstat width to 72 - 2018-02-01) makes sure that default stat width will be 72 (ignoring $COLUMNS, but could still be overriden by --stat). So all we need to do here is drop the assignment. Reported-by: Laszlo Ersek <lersek@redhat.com> Helped-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13refs: fix some exclude patterns being ignoredLibravatar Rafael Ascensão1-12/+12
`--exclude` from rev-list and rev-parse fails to exclude references if the next `--branches`, `--tags` or `--remotes` use the optional inclusive glob because those options are implemented as particular cases of `--glob=`, which itself requires that exclude patterns begin with 'refs/'. But it makes sense for `--branches=glob` and friends to be aware that exclusions patterns for them shouldn't be 'refs/<type>/' prefixed, the same way exclude patterns for `--branches` and friends (without the optional glob) already are. Let's record in 'refs.c:struct ref_filter' which context the exclude pattern is tied to, so refs.c:filter_refs() can decide if it should ignore the prefix when trying to match. Signed-off-by: Rafael Ascensão <rafa.almas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13refs: show --exclude failure with --branches/tags/remotes=globLibravatar Rafael Ascensão1-3/+57
The documentation of `--exclude=` option from rev-list and rev-parse explicitly states that exclude patterns *should not* start with 'refs/' when used with `--branches`, `--tags` or `--remotes`. However, following this advice results in refereces not being excluded if the next `--branches`, `--tags`, `--remotes` use the optional inclusive glob. Demonstrate this failure. Signed-off-by: Rafael Ascensão <rafa.almas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13apply --recount: allow "no-op hunks"Libravatar Johannes Schindelin1-0/+12
When editing patches e.g. in `git add -e`, it is quite common that a hunk ends up having no -/+ lines, i.e. it is now supposed to do nothing. This use case was broken by ad6e8ed37bc1 (apply: reject a hunk that does not do anything, 2015-06-01) with the good intention of catching a very real, different issue in hand-edited patches. So let's use the `--recount` option as the tell-tale whether the user would actually be okay with no-op hunks. Add a test case to make sure that this use case does not regress again. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13rebase -r: do not write MERGE_HEAD unless neededLibravatar Johannes Schindelin1-1/+1
When we detect that a `merge` can be skipped because the merged commit is already an ancestor of HEAD, we do not need to commit, therefore writing the MERGE_HEAD file is useless. It is actually worse than useless: a subsequent `git commit` will pick it up and think that we want to merge that commit, still. To avoid that, move the code that writes the MERGE_HEAD file to a location where we already know that the `merge` cannot be skipped. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13rebase -r: demonstrate bug with conflicting mergesLibravatar Johannes Schindelin1-0/+16
When calling `merge` on a branch that has already been merged, that `merge` is skipped quietly, but currently a MERGE_HEAD file is being left behind and will then be grabbed by the next `pick` (that did not want to create a *merge* commit). Demonstrate this. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-12p3400: replace calls to `git checkout -b' by `git checkout -B'Libravatar Alban Gruin1-5/+5
p3400 makes a copy of the current repository to test git-rebase performance, and creates new branches in the copy with `git checkout -b'. If the original repository has branches with the same name as the script is trying to create, this operation will fail. This replaces these calls by `git checkout -B' to force the creation and update of these branches. Signed-off-by: Alban Gruin <alban.gruin@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-12range-diff: fix regression in passing along diff optionsLibravatar Ævar Arnfjörð Bjarmason1-0/+53
In 73a834e9e2 ("range-diff: relieve callers of low-level configuration burden", 2018-07-22) we broke passing down options like --no-patch, --stat etc. Fix that regression, and add a test asserting the pre-73a834e9e2 behavior for some of these diff options. As noted in a change leading up to this ("range-diff doc: add a section about output stability", 2018-11-07) the output is not meant to be stable. So this regression test will likely need to be tweaked once we get a "proper" --stat option. See https://public-inbox.org/git/nycvar.QRO.7.76.6.1811071202480.39@tvgsbejvaqbjf.bet/ for a further explanation of the regression. The fix here is not the same as in Johannes's on-list patch, for reasons that'll be explained in a follow-up commit. The quoting of "EOF" here mirrors that of an earlier test. Perhaps that should be fixed, but let's leave that up to a later cleanup change. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-09i18n: make GETTEXT_POISON a runtime optionLibravatar Ævar Arnfjörð Bjarmason9-19/+40
Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON test parameter to only be a GIT_TEST_GETTEXT_POISON=<non-empty?> runtime parameter, to be consistent with other parameters documented in "Running tests with special setups" in t/README. When I added GETTEXT_POISON in bb946bba76 ("i18n: add GETTEXT_POISON to simulate unfriendly translator", 2011-02-22) I was concerned with ensuring that the _() function would get constant folded if NO_GETTEXT was defined, and likewise that GETTEXT_POISON would be compiled out unless it was defined. But as the benchmark in my [1] shows doing a one-off runtime getenv("GIT_TEST_[...]") is trivial, and since GETTEXT_POISON was originally added the GIT_TEST_* env variables have become the common idiom for turning on special test setups. So change GETTEXT_POISON to work the same way. Now the GETTEXT_POISON=YesPlease compile-time option is gone, and running the tests with GIT_TEST_GETTEXT_POISON=[YesPlease|] can be toggled on/off without recompiling. This allows for conditionally amending tests to test with/without poison, similar to what 859fdc0c3c ("commit-graph: define GIT_TEST_COMMIT_GRAPH", 2018-08-29) did for GIT_TEST_COMMIT_GRAPH. Do some of that, now we e.g. always run the t0205-gettext-poison.sh test. I did enough there to remove the GETTEXT_POISON prerequisite, but its inverse C_LOCALE_OUTPUT is still around, and surely some tests using it can be converted to e.g. always set GIT_TEST_GETTEXT_POISON=. Notes on the implementation: * We still compile a dedicated GETTEXT_POISON build in Travis CI. Perhaps this should be revisited and integrated into the "linux-gcc" build, see ae59a4e44f ("travis: run tests with GIT_TEST_SPLIT_INDEX", 2018-01-07) for prior art in that area. Then again maybe not, see [2]. * We now skip a test in t0000-basic.sh under GIT_TEST_GETTEXT_POISON=YesPlease that wasn't skipped before. This test relies on C locale output, but due to an edge case in how the previous implementation of GETTEXT_POISON worked (reading it from GIT-BUILD-OPTIONS) wasn't enabling poison correctly. Now it does, and needs to be skipped. * The getenv() function is not reentrant, so out of paranoia about code of the form: printf(_("%s"), getenv("some-env")); call use_gettext_poison() in our early setup in git_setup_gettext() so we populate the "poison_requested" variable in a codepath that's won't suffer from that race condition. * We error out in the Makefile if you're still saying GETTEXT_POISON=YesPlease to prompt users to change their invocation. * We should not print out poisoned messages during the test initialization itself to keep it more readable, so the test library hides the variable if set in $GIT_TEST_GETTEXT_POISON_ORIG during setup. See [3]. See also [4] for more on the motivation behind this patch, and the history of the GETTEXT_POISON facility. 1. https://public-inbox.org/git/871s8gd32p.fsf@evledraar.gmail.com/ 2. https://public-inbox.org/git/20181102163725.GY30222@szeder.dev/ 3. https://public-inbox.org/git/20181022202241.18629-2-szeder.dev@gmail.com/ 4. https://public-inbox.org/git/878t2pd6yu.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-08built-in rebase --autostash: leave the current branch alone if possibleLibravatar Johannes Schindelin1-1/+1
When we converted a `git reset --hard` call in the original Unix shell script to built-in code, we asked to reset the worktree and the index and explicitly *not* to detach the HEAD. By mistake, though, we still did. Let's fix this. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-08built-in rebase: demonstrate regression with --autostashLibravatar Johannes Schindelin1-0/+8
An unnamed colleague of Ævar Arnfjörð Bjarmason reported a breakage where a `pull --rebase` (which did not really need to do anything but stash, see that nothing was changed, and apply the stash again) also detached the HEAD. This patch adds a minimal reproducer for this regression. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-07approxidate: fix NULL dereference in date_time()Libravatar Jeff King1-0/+1
When we see a time like "noon", we pass "12" to our date_time() helper, which sets the hour to 12pm. If the current time is before noon, then we wrap around to yesterday using date_yesterday(). But unlike the normal calls to date_yesterday() from approxidate_alpha(), we pass a NULL "num" parameter. Since c27cc94fad (approxidate: handle pending number for "specials", 2018-11-02), that causes a segfault. One way to fix this is by checking for NULL. But arguably date_time() is abusing our helper by passing NULL in the first place (and this is the only case where one of these "special" parsers is used this way). So instead, let's have it just do the 1-day subtraction itself. It's still just a one-liner due to our update_tm() helper. Note that the test added here is a little funny, as we say "10am noon", which makes the "10am" seem pointless. But this bug can only be triggered when it the currently-parsed hour is before the special time. The latest special time is "tea" at 1700, but t0006 uses a hard-coded TEST_DATE_NOW of 1900. We could reset TEST_DATE_NOW, but that may lead to confusion in other tests. Just saying "10am noon" makes this test self-contained. Reported-by: Carlo Arenas <carenas@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>