1. 25 Mar, 2018 1 commit
  2. 19 Jan, 2018 4 commits
  3. 16 Jan, 2018 3 commits
  4. 09 Jan, 2018 13 commits
  5. 05 Jan, 2018 10 commits
  6. 04 Jan, 2018 2 commits
    • Jeff King's avatar
      docs/diff-options: clarify scope of diff-filter types · 46af107b
      Jeff King authored
      The same document for "--diff-filter" is included by many
      programs in the diff family. Because it mentions all
      possible types (added, removed, etc), this may imply to the
      reader that all types can be generated by a particular
      command. But this isn't necessarily the case; "diff-files"
      cannot generally produce an "Added" entry, since the diff is
      limited to what is already in the index.
      Let's make it clear that the list here is the full one, and
      does not imply anything about what a particular invocation
      may produce.
      Note that conditionally including items (e.g., omitting
      "Added" in the git-diff-files manpage) isn't the right
      solution here for two reasons:
        - The problem isn't diff-files, but doing an index to
          working tree diff. "git diff" can do the same diff, but
          also has other modes where "Added" does show up.
        - The direction of the diff matters. Doing "diff-files -R"
          can get you Added entries (but not Deleted ones).
      So it's best just to explain that the set of available types
      depends on the specific diff invocation.
      Reported-by: John Cheng's avatarJohn Cheng <johnlicheng@gmail.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Todd Zullinger's avatar
      http: fix v1 protocol tests with apache httpd < 2.4 · a812952a
      Todd Zullinger authored
      The apache config used by tests was updated to use the SetEnvIf
      directive to set the Git-Protocol header in 19113a26 ("http: tell
      server that the client understands v1", 2017-10-16).
      Setting the Git-Protocol header is restricted to httpd >= 2.4, but
      mod_setenvif and the SetEnvIf directive work with lower versions, at
      least as far back as 2.0, according to the httpd documentation:
      Drop the restriction.  Tested with httpd 2.2 and 2.4.
      Signed-off-by: Todd Zullinger's avatarTodd Zullinger <tmz@pobox.com>
      Acked-by: default avatarBrandon Williams <bmwill@google.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  7. 03 Jan, 2018 5 commits
    • Johannes Schindelin's avatar
      t0302 & t3900: add forgotten quotes · 89a70b80
      Johannes Schindelin authored
      When cleaning up files in the $HOME directory, it really makes sense to
      quote the path, especially in Git's test suite, where the HOME directory
      is *guaranteed* to contain spaces in its name.
      It would appear that those two tests pass even without cleaning up the
      files, but really more by pure chance than by design (the cleanup seems
      not actually to be necessary).
      However, if anybody would have a left-over `trash/` directory in Git's
      `t/` directory, these tests would fail, because they would all of a
      sudden try to delete that directory, but without the `-r` (recursive)
      flag. That is how this issue was found.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Reviewed-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Johannes Schindelin's avatar
      Allow the test suite to pass in a directory whose name contains spaces · 567c53d0
      Johannes Schindelin authored
      It is totally legitimate to clone Git's source code anywhere, including
      into, say, directories whose name (or the name of its absolute path)
      contains spaces.
      However, a couple of tests failed to anticipate this, for lack of
      quoting (or in one instance, for failure to expect more than one space
      in the absolute path of the TEST_DIRECTORY). This can be easily verified
      by calling these commands in your current clone:
      	git clone . with\ spaces
      	cd with\ spaces
      	make -j15 test
      Let's fix this.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Reviewed-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Todd Zullinger's avatar
      doc/SubmittingPatches: improve text formatting · c9e3d472
      Todd Zullinger authored
      049e64aa ("Documentation: convert SubmittingPatches to AsciiDoc",
      2017-11-12) changed the `git blame` and `git shortlog` examples given in
      the section on sending your patches.
      In order to italicize the `$path` argument the commands are enclosed in
      plus characters as opposed to backticks.  The difference between the
      quoting methods is that backtick enclosed text is not subject to further
      expansion.  This formatting makes reading SubmittingPatches in a git
      clone a little more difficult.  In addition to the underscores around
      `$path` the `--` chars in `git shortlog --no-merges` must be replaced
      with `{litdd}`.
      Use backticks to quote these commands.  The italicized `$path` is lost
      from the html version but the commands can be read (and copied) more
      easily by users reading the text version.  These readers are more likely
      to use the commands while submitting patches.  Make it easier for them.
      Signed-off-by: Todd Zullinger's avatarTodd Zullinger <tmz@pobox.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Gábor Szeder's avatar
      travis-ci: check that all build artifacts are .gitignore-d · b92cb86e
      Gábor Szeder authored
      Every once in a while our explicit .gitignore files get out of sync
      when our build process learns to create new artifacts, like test
      helper executables, but the .gitignore files are not updated
      Use Travis CI to help catch such issues earlier: check that there are
      no untracked files at the end of any build jobs building Git (i.e. the
      64 bit Clang and GCC Linux and OSX build jobs, plus the GETTEXT_POISON
      and 32 bit Linux build jobs) or its documentation, and fail the build
      job if there are any present.
      Signed-off-by: Gábor Szeder's avatarSZEDER Gábor <szeder.dev@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Gábor Szeder's avatar
      travis-ci: don't store P4 and Git LFS in the working tree · 88e00b70
      Gábor Szeder authored
      The Clang and GCC 64 bit Linux build jobs download and store the P4
      and Git LFS executables under the current directory, which is the
      working tree that we are about to build and test.  This means that Git
      commands like 'status' or 'ls-files' would list these files as
      untracked.  The next commit is about to make sure that there are no
      untracked files present after the build, and the downloaded
      executables in the working tree are interfering with those upcoming
      Therefore, let's download P4 and Git LFS in the home directory,
      outside of the working tree.
      Signed-off-by: Gábor Szeder's avatarSZEDER Gábor <szeder.dev@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  8. 02 Jan, 2018 2 commits
    • Gábor Szeder's avatar
      travis-ci: record and skip successfully built trees · 9cc2c76f
      Gábor Szeder authored
      Travis CI dutifully builds and tests each new branch tip, even if its
      tree has previously been successfully built and tested.  This happens
      often enough in contributors' workflows, when a work-in-progress
      branch is rebased changing e.g. only commit messages or the order or
      number of commits while leaving the resulting code intact, and is then
      pushed to a Travis CI-enabled GitHub fork.
      This is wasting Travis CI's resources and is sometimes scary-annoying
      when the new tip commit with a tree identical to the previous,
      successfully tested one is suddenly reported in red, because one of
      the OSX build jobs happened to exceed the time limit yet again.
      So extend our Travis CI build scripts to skip building commits whose
      trees have previously been successfully built and tested.  Use the
      Travis CI cache feature to keep a record of the object names of trees
      that tested successfully, in a plain and simple flat text file, one
      line per tree object name.  Append the current tree's object name at
      the end of every successful build job to this file, along with a bit
      of additional info about the build job (commit object name, Travis CI
      job number and id).  Limit the size of this file to 1000 records, to
      prevent it from growing too large for git/git's forever living
      integration branches.  Check, using a simple grep invocation, in each
      build job whether the current commit's tree is already in there, and
      skip the build if it is.  Include a message in the skipped build job's
      trace log, containing the URL to the build job successfully testing
      that tree for the first time and instructions on how to force a
      re-build.  Catch the case when a build job, which successfully built
      and tested a particular tree for the first time, is restarted and omit
      the URL of the previous build job's trace log, as in this case it's
      the same build job and the trace log has just been overwritten.
      Note: this won't kick in if two identical trees are on two different
      branches, because Travis CI caches are not shared between build jobs
      of different branches.
      Signed-off-by: Gábor Szeder's avatarSZEDER Gábor <szeder.dev@gmail.com>
      Reviewed-by: default avatarLars Schneider <larsxschneider@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Gábor Szeder's avatar
      travis-ci: create the cache directory early in the build process · b4a2fdc9
      Gábor Szeder authored
      It seems that Travis CI creates the cache directory for us anyway,
      even when a previous cache doesn't exist for the current build job.
      Alas, this behavior is not explicitly documented, therefore we don't
      rely on it and create the cache directory ourselves in those build
      jobs that read/write cached data (currently only the prove state).
      In the following commit we'll start to cache additional data in every
      build job, and will access the cache much earlier in the build
      Therefore move creating the cache directory to 'ci/lib-travisci.sh' to
      make sure that it exists at the very beginning of every build job.
      Signed-off-by: Gábor Szeder's avatarSZEDER Gábor <szeder.dev@gmail.com>
      Reviewed-by: default avatarLars Schneider <larsxschneider@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>