1. 01 Apr, 2019 3 commits
  2. 20 Mar, 2019 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      rebase: remove the rebase.useBuiltin setting · d03ebd41
      Ævar Arnfjörð Bjarmason authored
      Remove the rebase.useBuiltin setting, which was added as an escape
      hatch to disable the builtin version of rebase first released with Git
      2.20.
      
      See [1] for the initial implementation of rebase.useBuiltin, and [2]
      and [3] for the documentation and corresponding
      GIT_TEST_REBASE_USE_BUILTIN option.
      
      Carrying the legacy version is a maintenance burden as seen in
      7e097e27 ("legacy-rebase: backport -C<n> and --whitespace=<option>
      checks", 2018-11-20) and 9aea5e92 ("rebase: fix regression in
      rebase.useBuiltin=false test mode", 2019-02-13). Since the built-in
      version has been shown to be stable enough let's remove the legacy
      version.
      
      As noted in [3] having use_builtin_rebase() shell out to get its
      config doesn't make any sense anymore, that was done for the purposes
      of spawning the legacy rebase without having modified any global
      state. Let's instead handle this case in rebase_config().
      
      There's still a bunch of references to git-legacy-rebase in po/*.po,
      but those will be dealt with in time by the i18n effort.
      
      Even though this configuration variable only existed two releases
      let's not entirely delete the entry from the docs, but note its
      absence. Individual versions of git tend to be around for a while due
      to distro packaging timelines, so e.g. if we're "lucky" a given
      version like 2.21 might be installed on say OSX for half a decade.
      
      That'll mean some people probably setting this in config, and then
      when they later wonder if it's needed they can Google search the
      config option name or check it in git-config. It also allows us to
      refer to the docs from the warning for details.
      
      1. 55071ea2 ("rebase: start implementing it as a builtin",
         2018-08-07)
      2. d8d0a546 ("rebase doc: document rebase.useBuiltin", 2018-11-14)
      3. 62c23938 ("tests: add a special setup where rebase.useBuiltin is
         off", 2018-11-14)
      3. https://public-inbox.org/git/nycvar.QRO.7.76.6.1903141544110.41@tvgsbejvaqbjf.bet/Acked-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d03ebd41
  3. 13 Mar, 2019 1 commit
    • Jeff King's avatar
      Makefile: fix unaligned loads in sha1dc with UBSan · 07a20f56
      Jeff King authored
      The sha1dc library uses unaligned loads on platforms that support them.
      This is normally what you'd want for performance, but it does cause
      UBSan to complain when we compile with SANITIZE=undefined. Just like we
      set -DNO_UNALIGNED_LOADS for our own code in that case, we should set
      -DSHA1DC_FORCE_ALIGNED_ACCESS.
      
      Of course that does nothing without pulling in the patches from sha1dc
      to respect that define. So let's do that, too, updating both the
      submodule link and our in-tree copy (from the same commit).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      07a20f56
  4. 07 Mar, 2019 3 commits
  5. 06 Mar, 2019 1 commit
  6. 05 Mar, 2019 1 commit
    • Johannes Schindelin's avatar
      Makefile: use `git ls-files` to list header files, if possible · 92b88eba
      Johannes Schindelin authored
      In d85b0dff (Makefile: use `find` to determine static header
      dependencies, 2014-08-25), we switched from a static list of header
      files to a dynamically-generated one, asking `find` to enumerate them.
      
      Back in those days, we did not use `$(LIB_H)` by default, and many a
      `make` implementation seems smart enough not to run that `find` command
      in that case, so it was deemed okay to run `find` for special targets
      requiring this macro.
      
      However, as of ebb7baf0 (Makefile: add a hdr-check target,
      2018-09-19), $(LIB_H) is part of a global rule and therefore must be
      expanded. Meaning: this `find` command has to be run upon every
      `make` invocation. In the presence of many a worktree, this can tax the
      developers' patience quite a bit.
      
      Even in the absence of worktrees or other untracked files and
      directories, the cost of I/O to generate that list of header files is
      simply a lot larger than a simple `git ls-files` call.
      
      Therefore, just like in 33533975 (Makefile: ask "ls-files" to list
      source files if available, 2011-10-18), we now prefer to use `git
      ls-files` to enumerate the header files to enumerating them via `find`,
      falling back to the latter if the former failed (which would be the case
      e.g. in a worktree that was extracted from a source .tar file rather
      than from a clone of Git's sources).
      
      This has one notable consequence: we no longer include `command-list.h`
      in `LIB_H`, as it is a generated file, not a tracked one, but that is
      easily worked around. Of the three sites that use `LIB_H`, two
      (`LOCALIZED_C` and `CHK_HDRS`) already handle generated headers
      separately. In the third, the computed-dependency fallback, we can just
      add in a reference to $(GENERATED_H).
      
      Likewise, we no longer include not-yet-tracked header files in `LIB_H`.
      
      Given the speed improvements, these consequences seem a comparably small
      price to pay.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Acked-by: default avatarRamsay Jones <ramsay@ramsayjones.plus.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      92b88eba
  7. 24 Feb, 2019 6 commits
  8. 22 Feb, 2019 2 commits
    • Jeff Hostetler's avatar
      trace2: t/helper/test-trace2, t0210.sh, t0211.sh, t0212.sh · a15860dc
      Jeff Hostetler authored
      Create unit tests for Trace2.
      Signed-off-by: default avatarJeff Hostetler <jeffhost@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a15860dc
    • Jeff Hostetler's avatar
      trace2: create new combined trace facility · ee4512ed
      Jeff Hostetler authored
      Create a new unified tracing facility for git.  The eventual intent is to
      replace the current trace_printf* and trace_performance* routines with a
      unified set of git_trace2* routines.
      
      In addition to the usual printf-style API, trace2 provides higer-level
      event verbs with fixed-fields allowing structured data to be written.
      This makes post-processing and analysis easier for external tools.
      
      Trace2 defines 3 output targets.  These are set using the environment
      variables "GIT_TR2", "GIT_TR2_PERF", and "GIT_TR2_EVENT".  These may be
      set to "1" or to an absolute pathname (just like the current GIT_TRACE).
      
      * GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command
        summary data.
      
      * GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE.
        It extends the output with columns for the command process, thread,
        repo, absolute and relative elapsed times.  It reports events for
        child process start/stop, thread start/stop, and per-thread function
        nesting.
      
      * GIT_TR2_EVENT is a new structured format. It writes event data as a
        series of JSON records.
      
      Calls to trace2 functions log to any of the 3 output targets enabled
      without the need to call different trace_printf* or trace_performance*
      routines.
      Signed-off-by: default avatarJeff Hostetler <jeffhost@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ee4512ed
  9. 19 Feb, 2019 1 commit
    • Johannes Schindelin's avatar
      tests: teach the test-tool to generate NUL bytes and use it · d5cfd142
      Johannes Schindelin authored
      In cc95bc20 (t5562: replace /dev/zero with a pipe from
      generate_zero_bytes, 2019-02-09), we replaced usage of /dev/zero (which
      is not available on NonStop, apparently) by a Perl script snippet to
      generate NUL bytes.
      
      Sadly, it does not seem to work on NonStop, as t5562 reportedly hangs.
      
      Worse, this also hangs in the Ubuntu 16.04 agents of the CI builds on
      Azure Pipelines: for some reason, the Perl script snippet that is run
      via `generate_zero_bytes` in t5562's 'CONTENT_LENGTH overflow ssite_t'
      test case tries to write out an infinite amount of NUL bytes unless a
      broken pipe is encountered, that snippet never encounters the broken
      pipe, and keeps going until the build times out.
      
      Oddly enough, this does not reproduce on the Windows and macOS agents,
      nor in a local Ubuntu 18.04.
      
      This developer tried for a day to figure out the exact circumstances
      under which this hang happens, to no avail, the details remain a
      mystery.
      
      In the end, though, what counts is that this here change incidentally
      fixes that hang (maybe also on NonStop?). Even more positively, it gets
      rid of yet another unnecessary Perl invocation.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d5cfd142
  10. 12 Feb, 2019 2 commits
    • Duy Nguyen's avatar
      git-compat-util: work around fileno(fp) that is a macro · 18a4f6be
      Duy Nguyen authored
      On various BSD's, fileno(fp) is implemented as a macro that directly
      accesses the fields in the FILE * object, which breaks a function that
      accepts a "void *fp" parameter and calls fileno(fp) and expect it to
      work.
      
      Work it around by adding a compile-time knob FILENO_IS_A_MACRO that
      inserts a real helper function in the middle of the callchain.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      18a4f6be
    • brian m. carlson's avatar
      utf8: handle systems that don't write BOM for UTF-16 · 79444c92
      brian m. carlson authored
      When serializing UTF-16 (and UTF-32), there are three possible ways to
      write the stream. One can write the data with a BOM in either big-endian
      or little-endian format, or one can write the data without a BOM in
      big-endian format.
      
      Most systems' iconv implementations choose to write it with a BOM in
      some endianness, since this is the most foolproof, and it is resistant
      to misinterpretation on Windows, where UTF-16 and the little-endian
      serialization are very common. For compatibility with Windows and to
      avoid accidental misuse there, Git always wants to write UTF-16 with a
      BOM, and will refuse to read UTF-16 without it.
      
      However, musl's iconv implementation writes UTF-16 without a BOM,
      relying on the user to interpret it as big-endian. This causes t0028 and
      the related functionality to fail, since Git won't read the file without
      a BOM.
      
      Add a Makefile and #define knob, ICONV_OMITS_BOM, that can be set if the
      iconv implementation has this behavior. When set, Git will write a BOM
      manually for UTF-16 and UTF-32 and then force the data to be written in
      UTF-16BE or UTF-32BE. We choose big-endian behavior here because the
      tests use the raw "UTF-16" encoding, which will be big-endian when the
      implementation requires this knob to be set.
      
      Update the tests to detect this case and write test data with an added
      BOM if necessary. Always write the BOM in the tests in big-endian
      format, since all iconv implementations that omit a BOM must use
      big-endian serialization according to the Unicode standard.
      
      Preserve the existing behavior for systems which do not have this knob
      enabled, since they may use optimized implementations, including
      defaulting to the native endianness, which may improve performance.
      Signed-off-by: brian m. carlson's avatarbrian m. carlson <sandals@crustytoothpaste.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      79444c92
  11. 05 Feb, 2019 1 commit
    • Ramsay Jones's avatar
      Makefile: improve SPARSE_FLAGS customisation · 15caca28
      Ramsay Jones authored
      In order to enable greater user customisation of the SPARSE_FLAGS
      variable, we introduce a new SP_EXTRA_FLAGS variable to use for
      target specific settings. Without using the new variable, setting
      the SPARSE_FLAGS on the 'make' command-line would also override the
      value set by the target-specific rules in the Makefile (effectively
      making them useless). Also, this enables the SP_EXTRA_FLAGS to be
      used in the future for any other internal customisations, such as
      for some platform specific values.
      
      In addition, we initialise the SPARSE_FLAGS to the default (empty)
      value using a conditional assignment (?=). This allows SPARSE_FLAGS
      to be set from the environment as well as from the command-line.
      Signed-off-by: default avatarRamsay Jones <ramsay@ramsayjones.plus.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      15caca28
  12. 29 Jan, 2019 3 commits
    • Derrick Stolee's avatar
      Makefile: add coverage-prove target · 2299120f
      Derrick Stolee authored
      Sometimes there are test failures in the 'pu' branch. This
      is somewhat expected for a branch that takes the very latest
      topics under development, and those sometimes have semantic
      conflicts that only show up during test runs. This also can
      happen when running the test suite with different GIT_TEST_*
      environment variables that interact in unexpected ways
      
      This causes a problem for the test coverage reports, as
      the typical 'make coverage-test coverage-report' run halts
      at the first failed test. If that test is early in the
      suite, then many valuable tests are not exercising the code
      and the coverage report becomes noisy with false positives.
      
      Add a new 'coverage-prove' target to the Makefile,
      modeled after the 'coverage-test' target. This compiles
      the source using the coverage flags, then runs the test
      suite using the 'prove' tool. Since the coverage
      machinery is not thread-safe, enforce that the tests
      are run in sequence by appending '-j1' to GIT_PROVE_OPTS.
      Signed-off-by: Derrick Stolee's avatarDerrick Stolee <dstolee@microsoft.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      2299120f
    • Johannes Schindelin's avatar
      ci: parallelize testing on Windows · b819f1d2
      Johannes Schindelin authored
      The fact that Git's test suite is implemented in Unix shell script that
      is as portable as we can muster, combined with the fact that Unix shell
      scripting is foreign to Windows (and therefore has to be emulated),
      results in pretty abysmal speed of the test suite on that platform, for
      pretty much no other reason than that language choice.
      
      For comparison: while the Linux build & test is typically done within
      about 8 minutes, the Windows build & test typically lasts about 80
      minutes in Azure Pipelines.
      
      To help with that, let's use the Azure Pipeline feature where you can
      parallelize jobs, make jobs depend on each other, and pass artifacts
      between them.
      
      The tests are distributed using the following heuristic: listing all
      test scripts ordered by size in descending order (as a cheap way to
      estimate the overall run time), every Nth script is run (where N is the
      total number of parallel jobs), starting at the index corresponding to
      the parallel job. This slicing is performed by a new function that is
      added to the `test-tool`.
      
      To optimize the overall runtime of the entire Pipeline, we need to move
      the Windows jobs to the beginning (otherwise there would be a very
      decent chance for the Pipeline to be run only the Windows build, while
      all the parallel Windows test jobs wait for this single one).
      
      We use Azure Pipelines Artifacts for both the minimal Git for Windows
      SDK as well as the built executables, as deduplication and caching close
      to the agents makes that really fast. For comparison: while downloading
      and unpacking the minimal Git for Windows SDK via PowerShell takes only
      one minute (down from anywhere between 2.5 to 7 when using a shallow
      clone), uploading it as Pipeline Artifact takes less than 30s and
      downloading and unpacking less than 20s (sometimes even as little as
      only twelve seconds).
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      b819f1d2
    • Johannes Schindelin's avatar
      tests: optionally write results as JUnit-style .xml · 22231908
      Johannes Schindelin authored
      This will come in handy when publishing the results of Git's test suite
      during an automated Azure DevOps run.
      
      Note: we need to make extra sure that invalid UTF-8 encoding is turned
      into valid UTF-8 (using the Replacement Character, \uFFFD) because
      t9902's trace contains such invalid byte sequences, and the task in the
      Azure Pipeline that uploads the test results would refuse to do anything
      if it was asked to parse an .xml file with invalid UTF-8 in it.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      22231908
  13. 16 Jan, 2019 2 commits
    • Josh Steadmon's avatar
      Makefile: correct example fuzz build · 8b7c2eee
      Josh Steadmon authored
      The comment explaining how to build the fuzzers was broken in
      927c77e7 ("Makefile: use FUZZ_CXXFLAGS for linking fuzzers",
      2018-11-14).
      
      When building fuzzers, all .c files must be compiled with coverage
      tracing enabled. This is not possible when using only FUZZ_CXXFLAGS, as
      that flag is only applied to the fuzzers themselves. Switching back to
      CFLAGS fixes the issue.
      Signed-off-by: default avatarJosh Steadmon <steadmon@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8b7c2eee
    • Josh Steadmon's avatar
      commit-graph, fuzz: add fuzzer for commit-graph · aa658574
      Josh Steadmon authored
      Break load_commit_graph_one() into a new function, parse_commit_graph().
      The latter function operates on arbitrary buffers, which makes it
      suitable as a fuzzing target. Since parse_commit_graph() is only called
      by load_commit_graph_one() (and the fuzzer described below), we omit
      error messages that would be duplicated by the caller.
      
      Adds fuzz-commit-graph.c, which provides a fuzzing entry point
      compatible with libFuzzer (and possibly other fuzzing engines).
      Signed-off-by: default avatarJosh Steadmon <steadmon@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      aa658574
  14. 07 Jan, 2019 1 commit
    • Elijah Newren's avatar
      rebase: implement --merge via the interactive machinery · 68aa495b
      Elijah Newren authored
      As part of an ongoing effort to make rebase have more uniform behavior,
      modify the merge backend to behave like the interactive one, by
      re-implementing it on top of the latter.
      
      Interactive rebases are implemented in terms of cherry-pick rather than
      the merge-recursive builtin, but cherry-pick also calls into the
      recursive merge machinery by default and can accept special merge
      strategies and/or special strategy options.  As such, there really is
      not any need for having both git-rebase--merge and
      git-rebase--interactive anymore.  Delete git-rebase--merge.sh and
      instead implement it in builtin/rebase.c.
      
      This results in a few deliberate but small user-visible changes:
        * The progress output is modified (see t3406 and t3420 for examples)
        * A few known test failures are now fixed (see t3421)
        * bash-prompt during a rebase --merge is now REBASE-i instead of
          REBASE-m.  Reason: The prompt is a reflection of the backend in use;
          this allows users to report an issue to the git mailing list with
          the appropriate backend information, and allows advanced users to
          know where to search for relevant control files.  (see t9903)
      
      testcase modification notes:
        t3406: --interactive and --merge had slightly different progress output
               while running; adjust a test to match the new expectation
        t3420: these test precise output while running, but rebase--am,
               rebase--merge, and rebase--interactive all were built on very
               different commands (am, merge-recursive, cherry-pick), so the
               tests expected different output for each type.  Now we expect
               --merge and --interactive to have the same output.
        t3421: --interactive fixes some bugs in --merge!  Wahoo!
        t9903: --merge uses the interactive backend so the prompt expected is
               now REBASE-i.
      Signed-off-by: Elijah Newren's avatarElijah Newren <newren@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      68aa495b
  15. 16 Nov, 2018 2 commits
    • Josh Steadmon's avatar
      Makefile: use FUZZ_CXXFLAGS for linking fuzzers · 927c77e7
      Josh Steadmon authored
      OSS-Fuzz requires C++-specific flags to link fuzzers. Passing these in
      CFLAGS causes lots of build warnings. Using separate FUZZ_CXXFLAGS
      avoids this.
      Signed-off-by: default avatarJosh Steadmon <steadmon@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      927c77e7
    • Johannes Schindelin's avatar
      tests: explicitly use `git.exe` on Windows · 8abfdf44
      Johannes Schindelin authored
      On Windows, when we refer to `/an/absolute/path/to/git`, it magically
      resolves `git.exe` at that location. Except if something of the name
      `git` exists next to that `git.exe`. So if we call `$BUILD_DIR/git`, it
      will find `$BUILD_DIR/git.exe` *only* if there is not, say, a directory
      called `$BUILD_DIR/git`.
      
      Such a directory, however, exists in Git for Windows when building with
      Visual Studio (our Visual Studio project generator defaults to putting
      the build files into a directory whose name is the base name of the
      corresponding `.exe`).
      
      In the bin-wrappers/* scripts, we already take pains to use `git.exe`
      rather than `git`, as this could pick up the wrong thing on Windows
      (i.e. if there exists a `git` file or directory in the build directory).
      
      Now we do the same in the tests' start-up code.
      
      This also helps when testing an installed Git, as there might be even
      more likely some stray file or directory in the way.
      
      Note: the only way we can record whether the `.exe` suffix is by writing
      it to the `GIT-BUILD-OPTIONS` file and sourcing it at the beginning of
      `t/test-lib.sh`. This is not a requirement introduced by this patch, but
      we move the call to be able to use the `$X` variable that holds the file
      extension, if any.
      
      Note also: the many, many calls to `git this` and `git that` are
      unaffected, as the regular PATH search will find the `.exe` files on
      Windows (and not be confused by a directory of the name `git` that is
      in one of the directories listed in the `PATH` variable), while
      `/path/to/git` would not, per se, know that it is looking for an
      executable and happily prefer such a directory.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8abfdf44
  16. 14 Nov, 2018 7 commits
  17. 09 Nov, 2018 2 commits
    • Junio C Hamano's avatar
      Makefile: ease dynamic-gettext-poison transition · c6a9a30e
      Junio C Hamano authored
      Earlier we made the entire build to fail when GETTEXT_POISON=Yes is
      given to make, to notify those who did not notice that text poisoning
      is now a runtime behaviour.
      
      It turns out that this is too irritating for those who need to build
      and test different versions of Git that cross the boundary between
      history with and without this topic to switch between two
      environment variables.  Demote the error to a warning, so that you
      can say something like
      
          make GETTEXT_POISON=Yes GIT_TEST_GETTEXT_POISON=Yes test
      
      during the transition period, without having to worry about whether
      exact version you are testing has or does not have this topic.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c6a9a30e
    • Ævar Arnfjörð Bjarmason's avatar
      i18n: make GETTEXT_POISON a runtime option · 6cdccfce
      Ævar Arnfjörð Bjarmason authored
      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 bb946bba ("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 859fdc0c ("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 ae59a4e4 ("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's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      6cdccfce
  18. 07 Nov, 2018 1 commit