1. 11 Mar, 2016 1 commit
  2. 28 Feb, 2016 1 commit
  3. 25 Feb, 2016 1 commit
    • nsec: support NDK's crazy nanoseconds · 3d6a42d1
      Android NDK does not have a `struct timespec` in its `struct stat`
      for nanosecond support, instead it has a single nanosecond member inside
      the struct stat itself.  We will use that and use a macro to expand to
      the `st_mtim` / `st_mtimespec` definition on other systems (much like
      the existing `st_mtime` backcompat definition).
      Edward Thomson committed
  4. 23 Feb, 2016 2 commits
    • index: fix contradicting comparison · 0f1e2d20
      The overflow check in `read_reuc` tries to verify if the
      `git__strtol32` parses an integer bigger than UINT_MAX. The `tmp`
      variable is casted to an unsigned int for this and then checked
      for being greater than UINT_MAX, which obviously can never be
      true.
      
      Fix this by instead fixing the `mode` field's size in `struct
      git_index_reuc_entry` to `uint32_t`. We can now parse the int
      with `git__strtol64`, which can never return a value bigger than
      `UINT32_MAX`, and additionally checking if the returned value is
      smaller than zero.
      
      We do not need to handle overflows explicitly here, as
      `git__strtol64` returns an error when the returned value would
      overflow.
      Patrick Steinhardt committed
  5. 17 Feb, 2016 1 commit
    • index: allow read of index w/ illegal entries · 318b825e
      Allow `git_index_read` to handle reading existing indexes with
      illegal entries.  Allow the low-level `git_index_add` to add
      properly formed `git_index_entry`s even if they contain paths
      that would be illegal for the current filesystem (eg, `AUX`).
      Continue to disallow `git_index_add_bypath` from adding entries
      that are illegal universally illegal (eg, `.git`, `foo/../bar`).
      Edward Thomson committed
  6. 16 Feb, 2016 3 commits
  7. 11 Feb, 2016 1 commit
  8. 28 Dec, 2015 1 commit
  9. 16 Dec, 2015 4 commits
  10. 08 Dec, 2015 1 commit
    • index: always queue `remove_entry` for removal · b057fdef
      When replacing an index with a new one, we need to iterate
      through all index entries in order to determine which entries are
      equal. When it is not possible to re-use old entries for the new
      index, we move it into a list of entries that are to be removed
      and thus free'd.
      
      When we encounter a non-zero error code, though, we skip adding
      the current index entry to the remove-queue. `INSERT_MAP_EX`,
      which is the function last run before adding to the remove-queue,
      may return a positive non-zero code that indicates what exactly
      happened while inserting the element. In this case we skip adding
      the entry to the remove-queue but still continue the current
      operation, leading to a leak of the current entry.
      
      Fix this by checking for a negative return value instead of a
      non-zero one when we want to add the current index entry to the
      remove-queue.
      Patrick Steinhardt committed
  11. 03 Dec, 2015 1 commit
    • index: canonicalize inserted paths safely · 626f9e24
      When adding to the index, we look to see if a portion of the given
      path matches a portion of a path in the index.  If so, we will use
      the existing path information.  For example, when adding `foo/bar.c`,
      if there is an index entry to `FOO/other` and the filesystem is case
      insensitive, then we will put `bar.c` into the existing tree instead
      of creating a new one with a different case.
      
      Use `strncmp` to do that instead of `memcmp`.  When we `bsearch`
      into the index, we locate the position where the new entry would
      go.  The index entry at that position does not necessarily have
      a relation to the entry we're adding, so we cannot make assumptions
      and use `memcmp`.  Instead, compare them as strings.
      
      When canonicalizing paths, we look for the first index entry that
      matches a given substring.
      Edward Thomson committed
  12. 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
  13. 17 Nov, 2015 4 commits
    • racy: make git_index_read_index handle raciness · 5f32c506
      Ensure that `git_index_read_index` clears the uptodate bit on
      files that it modifies.
      
      Further, do not propagate the cache from an on-disk index into
      another on-disk index.  Although this should not be done, as
      `git_index_read_index` is used to bring an in-memory index into
      another index (that may or may not be on-disk), ensure that we do
      not accidentally bring in these bits when misused.
      Edward Thomson committed
    • index: clear uptodate bit on save · 27bc41cf
      The uptodate bit should have a lifecycle of a single read->write
      on the index.  Once the index is written, the files within it should
      be scanned for racy timestamps against the new index timestamp.
      Edward Thomson committed
    • index: don't detect raciness in uptodate entries · d1101263
      Keep track of entries that we believe are up-to-date, because we
      added the index entries since the index was loaded.  This prevents
      us from unnecessarily examining files that we wrote during the
      cleanup of racy entries (when we smudge racily clean files that have
      a timestamp newer than or equal to the index's timestamp when we
      read it).  Without keeping track of this, we would examine every
      file that we just checked out for raciness, since all their timestamps
      would be newer than the index's timestamp.
      Edward Thomson committed
    • racy-git: do a single index->workdir diff · cb0ff012
      When examining paths that are racily clean, do a single index->workdir
      diff over the entirety of the racily clean files, instead of a diff
      per file.
      Edward Thomson committed
  14. 12 Nov, 2015 2 commits
  15. 30 Oct, 2015 1 commit
  16. 28 Oct, 2015 1 commit
  17. 27 Oct, 2015 1 commit
    • reuc: Be smarter when inserting new REUC entries · d307a013
      Inserting new REUC entries can quickly become pathological given that
      each insert unsorts the REUC vector, and both subsequent lookups *and*
      insertions will require sorting it again before being successful.
      
      To avoid this, we're switching to `git_vector_insert_sorted`: this keeps
      the REUC vector constantly sorted and lets us use the `on_dup` callback
      to skip an extra binary search on each insertion.
      Vicent Marti committed
  18. 21 Oct, 2015 1 commit
  19. 30 Sep, 2015 1 commit
    • index: also try conflict mode when inserting · 21515f22
      When we do not trust the on-disk mode, we use the mode of an existing
      index entry.  This allows us to preserve executable bits on platforms
      that do not honor them on the filesystem.
      
      If there is no stage 0 index entry, also look at conflicts to attempt
      to answer this question:  prefer the data from the 'ours' side, then
      the 'theirs' side before falling back to the common ancestor.
      Edward Thomson committed
  20. 19 Sep, 2015 3 commits
  21. 08 Sep, 2015 2 commits
    • git_index_add: allow case changing renames · a32bc85e
      On case insensitive platforms, allow `git_index_add` to provide a new
      path for an existing index entry.  Previously, we would maintain the
      case in an index entry without the ability to change it (except by
      removing an entry and re-adding it.)
      
      Higher-level functions (like `git_index_add_bypath` and
      `git_index_add_frombuffers`) continue to keep the old path for easier
      usage.
      Edward Thomson committed
    • index: canonicalize directory case when adding · 280adb3f
      On case insensitive systems, when given a user-provided path in the
      higher-level index addition functions (eg `git_index_add_bypath` /
      `git_index_add_frombuffer`), examine the index to try to match the
      given path to an existing directory.
      
      Various mechanisms can cause the on-disk representation of a folder
      to not match the representation in HEAD or the index - for example,
      a case changing rename of some file `a/file.txt` to `A/file.txt`
      will update the paths in the index, but not rename the folder on
      disk.
      
      If a user subsequently adds `a/other.txt`, then this should be stored
      in the index as `A/other.txt`.
      Edward Thomson committed
  22. 04 Sep, 2015 2 commits
  23. 28 Aug, 2015 2 commits
  24. 14 Aug, 2015 1 commit
  25. 03 Aug, 2015 1 commit