1. 20 Apr, 2018 2 commits
    • tests: free the worktree in add_with_explicit_branch · 25100d6d
      Valgrind log:
      
      ==2711== 305 (48 direct, 257 indirect) bytes in 1 blocks are definitely lost in loss record 576 of 624
      ==2711==    at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==2711==    by 0x5E079E: git__calloc (util.h:99)
      ==2711==    by 0x5E0D21: open_worktree_dir (worktree.c:134)
      ==2711==    by 0x5E0F23: git_worktree_lookup (worktree.c:176)
      ==2711==    by 0x5E1972: git_worktree_add (worktree.c:388)
      ==2711==    by 0x551F23: test_worktree_worktree__add_with_explicit_branch (worktree.c:292)
      ==2711==    by 0x45853E: clar_run_test (clar.c:222)
      ==2711==    by 0x4587E1: clar_run_suite (clar.c:286)
      ==2711==    by 0x458B04: clar_parse_args (clar.c:362)
      ==2711==    by 0x458CAB: clar_test_run (clar.c:428)
      ==2711==    by 0x45665C: main (main.c:24)
      Etienne Samson committed
    • refspec: check for valid parameters in git_refspec__dwim_one · 592b200c
      CID:1383993, "In git_refspec__dwim_one: All paths that lead to this null pointer comparison already dereference the pointer earlier (CWE-476)"
      Etienne Samson committed
  2. 17 Apr, 2018 10 commits
  3. 16 Apr, 2018 5 commits
  4. 12 Apr, 2018 3 commits
    • revwalk: fix uninteresting revs sometimes not limiting graphwalk · 54fd80e3
      When we want to limit our graphwalk, we use the heuristic of checking
      whether the newest limiting (uninteresting) revision is newer than the
      oldest interesting revision. We do so by inspecting whether the first
      item's commit time of the user-supplied list of revisions is newer than
      the last added interesting revision. This is wrong though, as the user
      supplied list is in no way guaranteed to be sorted by increasing commit
      dates. This could lead us to abort the revwalk early before applying all
      relevant limiting revisions, outputting revisions which should in fact
      have been hidden.
      
      Fix the heuristic by instead checking whether _any_ of the limiting
      commits was made earlier than the last interesting commit. Add a test.
      Patrick Steinhardt committed
    • Merge pull request #4613 from pks-t/pks/local-fetch-symrefs · c587d806
      transports: local: fix assert when fetching into repo with symrefs
      Patrick Steinhardt committed
    • attr_file: fix handling of directory patterns with trailing spaces · 251d8771
      When comparing whether a path matches a directory rule, we pass the
      both the path and directory name to `fnmatch` with
      `GIT_ATTR_FNMATCH_DIRECTORY` being set. `fnmatch` expects the pattern to
      contain no trailing directory '/', which is why we try to always strip
      patterns of trailing slashes. We do not handle that case correctly
      though when the pattern itself has trailing spaces, causing the match to
      fail.
      
      Fix the issue by stripping trailing spaces and tabs for a rule previous
      to checking whether the pattern is a directory pattern with a trailing
      '/'. This replaces the whitespace-stripping in our ignore file parsing
      code, which was stripping whitespaces too late. Add a test to catch
      future breakage.
      Patrick Steinhardt committed
  5. 11 Apr, 2018 5 commits
  6. 10 Apr, 2018 2 commits
  7. 06 Apr, 2018 5 commits
  8. 05 Apr, 2018 2 commits
  9. 03 Apr, 2018 4 commits
  10. 02 Apr, 2018 1 commit
  11. 30 Mar, 2018 1 commit