1. 20 Jul, 2019 1 commit
  2. 18 Jul, 2019 1 commit
  3. 15 Jun, 2019 1 commit
  4. 25 Jan, 2019 2 commits
  5. 22 Jan, 2019 1 commit
  6. 01 Dec, 2018 2 commits
  7. 10 Jun, 2018 1 commit
  8. 06 Jun, 2018 1 commit
    • Fix stash save bug with fast path index check · 5a7d454b
      If the index contains stat data for a modified file, and the file is
      not racily dirty, and there exists an untracked working tree directory
      alphabetically after that file, and there are no other changes to the
      repo, then git_stash_save would fail. It would confuse the untracked
      working tree directory for the modified file, because they have the
      same sha: zero.  The wt directory has a sha of zero because it's a
      directory, and the file would have a zero sha because we wouldn't read
      the file -- we would just know that it doesn't match the index.  To
      fix this confusion, we simply check mode as well as SHA.
      David Turner committed
  9. 03 Jan, 2018 1 commit
    • diff_generate: avoid excessive stats of .gitattribute files · d8896bda
      When generating a diff between two trees, for each file that is to be
      diffed we have to determine whether it shall be treated as text or as
      binary files. While git has heuristics to determine which kind of diff
      to generate, users can also that default behaviour by setting or
      unsetting the 'diff' attribute for specific files.
      
      Because of that, we have to query gitattributes in order to determine
      how to diff the current files. Instead of hitting the '.gitattributes'
      file every time we need to query an attribute, which can get expensive
      especially on networked file systems, we try to cache them instead. This
      works perfectly fine for every '.gitattributes' file that is found, but
      we hit cache invalidation problems when we determine that an attribuse
      file is _not_ existing. We do create an entry in the cache for missing
      '.gitattributes' files, but as soon as we hit that file again we
      invalidate it and stat it again to see if it has now appeared.
      
      In the case of diffing large trees with each other, this behaviour is
      very suboptimal. For each pair of files that is to be diffed, we will
      repeatedly query every directory component leading towards their
      respective location for an attributes file. This leads to thousands or
      even hundreds of thousands of wasted syscalls.
      
      The attributes cache already has a mechanism to help in that scenario in
      form of the `git_attr_session`. As long as the same attributes session
      is still active, we will not try to re-query the gitmodules files at all
      but simply retain our currently cached results. To fix our problem, we
      can create a session at the top-most level, which is the initialization
      of the `git_diff` structure, and use it in order to look up the correct
      diff driver. As the `git_diff` structure is used to generate patches for
      multiple files at once, this neatly solves our problem by retaining the
      session until patches for all files have been generated.
      
      The fix has been tested with linux.git by calling
      `git_diff_tree_to_tree` and `git_diff_to_buf` with v4.10^{tree} and
      v4.14^{tree}.
      
                      | time    | .gitattributes stats
          without fix | 33.201s | 844614
          with fix    | 30.327s | 4441
      
      While execution only improved by roughly 10%, the stat(3) syscalls for
      .gitattributes files decreased by 99.5%. The benchmarks were quite
      simple with best-of-three timings on Linux ext4 systems. One can assume
      that for network based file systems the performance gain will be a lot
      larger due to a much higher latency.
      Patrick Steinhardt committed
  10. 30 Nov, 2017 1 commit
    • diff_generate: fix unsetting diff flags · 5ca3f115
      The macro `DIFF_FLAG_SET` can be used to set or unset a flag by
      modifying the diff's bitmask. While the case of setting the flag is
      handled correctly, the case of unsetting the flag was not. Instead of
      inverting the flags, we are inverting the value which is used to decide
      whether we want to set or unset the bits.
      
      The value being used here is a simple `bool` which is `false`. As that
      is being uplifted to `int` when getting the bitwise-complement, we will
      end up retaining all bits inside of the bitmask. As that's only ever
      used to set `GIT_DIFF_IGNORE_CASE`, we were actually always ignoring
      case for generated diffs.
      
      Fix that by instead getting the bitwise-complement of `FLAG`, not `VAL`.
      Patrick Steinhardt committed
  11. 18 Nov, 2017 1 commit
    • refcount: make refcounting conform to aliasing rules · 585b5dac
      Strict aliasing rules dictate that for most data types, you are not
      allowed to cast them to another data type and then access the casted
      pointers. While this works just fine for most compilers, technically we
      end up in undefined behaviour when we hurt that rule.
      
      Our current refcounting code makes heavy use of casting and thus
      violates that rule. While we didn't have any problems with that code,
      Travis started spitting out a lot of warnings due to a change in their
      toolchain. In the refcounting case, the code is also easy to fix:
      as all refcounting-statements are actually macros, we can just access
      the `rc` field directly instead of casting.
      
      There are two outliers in our code where that doesn't work. Both the
      `git_diff` and `git_patch` structures have specializations for generated
      and parsed diffs/patches, which directly inherit from them. Because of
      that, the refcounting code is only part of the base structure and not of
      the children themselves. We can help that by instead passing their base
      into `GIT_REFCOUNT_INC`, though.
      Patrick Steinhardt committed
  12. 03 Jul, 2017 1 commit
    • Make sure to always include "common.h" first · 0c7f49dd
      Next to including several files, our "common.h" header also declares
      various macros which are then used throughout the project. As such, we
      have to make sure to always include this file first in all
      implementation files. Otherwise, we might encounter problems or even
      silent behavioural differences due to macros or defines not being
      defined as they should be. So in fact, our header and implementation
      files should make sure to always include "common.h" first.
      
      This commit does so by establishing a common include pattern. Header
      files inside of "src" will now always include "common.h" as its first
      other file, separated by a newline from all the other includes to make
      it stand out as special. There are two cases for the implementation
      files. If they do have a matching header file, they will always include
      this one first, leading to "common.h" being transitively included as
      first file. If they do not have a matching header file, they instead
      include "common.h" as first file themselves.
      
      This fixes the outlined problems and will become our standard practice
      for header and source files inside of the "src/" from now on.
      Patrick Steinhardt committed
  13. 29 Dec, 2016 1 commit
  14. 24 Aug, 2016 1 commit
  15. 26 May, 2016 3 commits
  16. 03 May, 2016 1 commit
    • diff: simplify code for handling empty dirs · fe3057b4
      When determining diffs between two iterators we may need to
      recurse into an unmatched directory for the "new" iterator when
      it is either a prefix to the current item of the "old" iterator
      or when untracked/ignored changes are requested by the user and
      the directory is untracked/ignored.
      
      When advancing into the directory and no files are found, we will
      get back `GIT_ENOTFOUND`. If so, we simply skip the directory,
      handling resulting unmatched old items in the next iteration. The
      other case of `iterator_advance_into` returning either
      `GIT_NOERROR` or any other error but `GIT_ENOTFOUND` will be
      handled by the caller, which will now either compare the first
      directory entry of the "new" iterator in case of `GIT_ENOERROR`
      or abort on other cases.
      
      Improve readability of the code to make the above logic more
      clear.
      Patrick Steinhardt committed
  17. 24 Mar, 2016 1 commit
  18. 23 Mar, 2016 2 commits
  19. 11 Feb, 2016 1 commit
  20. 01 Dec, 2015 1 commit
  21. 23 Nov, 2015 1 commit
    • checkout: only consider nsecs when built that way · 25e84f95
      When examining the working directory and determining whether it's
      up-to-date, only consider the nanoseconds in the index entry when
      built with `GIT_USE_NSEC`.  This prevents us from believing that
      the working directory is always dirty when the index was originally
      written with a git client that uinderstands nsecs (like git 2.x).
      Edward Thomson committed
  22. 02 Nov, 2015 1 commit
  23. 28 Oct, 2015 1 commit
  24. 22 Oct, 2015 1 commit
    • diff: ignore nsecs when diffing · 7499eae9
      Although our index contains the literal time present in the index,
      we do not read nanoseconds from disk, and thus we should not use
      them in any comparisons, lest we always think our working directory
      is dirty.
      
      Guard this behind a `GIT_USE_NSECS` for future improvement.
      Edward Thomson committed
  25. 02 Oct, 2015 1 commit
  26. 19 Sep, 2015 2 commits
  27. 12 Sep, 2015 1 commit
    • diff: check pathspec on non-files · 8ab4d0e1
      When we're not doing pathspec matching, we let the iterator handle
      file matching for us.  However, we can only trust the iterator to
      return *files* that match the pattern, because the iterator must
      return directories that are not strictly in the pathlist, but that
      are the parents of files that match the pattern, so that diff can
      later recurse into them.
      
      Thus, diff must examine non-files explicitly before including them
      in the delta list.
      Edward Thomson committed
  28. 30 Aug, 2015 1 commit
  29. 28 Aug, 2015 2 commits
  30. 30 Jun, 2015 1 commit
  31. 26 Jun, 2015 1 commit
  32. 23 Jun, 2015 1 commit
    • Fixed GIT_DELTA_CONFLICTED not returned in some cases · 8d8a2eef
      If an index entry for a file that is not in HEAD is in conflicted state,
      when diffing HEAD with the index, the status field of the corresponding git_diff_delta was incorrectly reported as GIT_DELTA_ADDED instead of GIT_DELTA_CONFLICTED.
      
      This was due to handle_unmatched_new_item() initially setting the status
      to GIT_DELTA_CONFLICTED but then overriding it later with GIT_DELTA_ADDED.
      Pierre-Olivier Latour committed
  33. 22 Jun, 2015 1 commit
    • diff: check files with the same or newer timestamps · ff475375
      When a file on the workdir has the same or a newer timestamp than the
      index, we need to perform a full check of the contents, as the update of
      the file may have happened just after we wrote the index.
      
      The iterator changes are such that we can reach inside the workdir
      iterator from the diff, though it may be better to have an accessor
      instead of moving these structs into the header.
      Carlos Martín Nieto committed