1. 15 Jun, 2019 1 commit
  2. 25 Jan, 2019 1 commit
  3. 24 Jan, 2019 1 commit
    • index: preserve extension parsing errors · 0bf7e043
      Previously, we would clobber any extension-specific error message with
      an "extension is truncated" message. This makes `read_extension`
      correctly preserve those errors, takes responsibility for truncation
      errors, and adds a new message with the actual extension signature for
      unsupported mandatory extensions.
      Etienne Samson committed
  4. 22 Jan, 2019 1 commit
  5. 09 Jan, 2019 1 commit
  6. 06 Jan, 2019 2 commits
  7. 04 Jan, 2019 1 commit
  8. 04 Dec, 2018 4 commits
  9. 01 Dec, 2018 2 commits
  10. 14 Nov, 2018 1 commit
  11. 19 Oct, 2018 1 commit
    • index: fix adding index entries with conflicting files · 8b6e2895
      When adding an index entry "a/b/c" while an index entry "a/b" already
      exists, git will happily remove "a/b/c" and only add the new index
      entry:
      
          $ git init test
          Initialized empty Git repository in /tmp/test.repo/test/.git/
          $ touch x
          $ git add x
          $ rm x
          $ mkdir x
          $ touch x/y
          $ git add x/y
          $ git status
          A x/y
      
      The other way round, adding an index entry "a/b" with an entry "a/b/c"
      already existing is equivalent, where git will remove "a/b/c" and add
      "a/b".
      
      In contrast, libgit2 will currently fail to add these properly and
      instead complain about the entry appearing as both a file and a
      directory. This is a programming error, though: our current code already
      tries to detect and, in the case of `git_index_add`, to automatically
      replace such index entries. Funnily enough, we already remove the
      conflicting index entries, but instead of adding the new entry we then
      bail out afterwards. This leaves callers with the worst of both worlds:
      we both remove the old entry but fail to add the new one.
      
      The root cause is weird semantics of the `has_file_name` and
      `has_dir_name` functions. While these functions only sound like they are
      responsible for detecting such conflicts, they will also already remove
      them in case where its `ok_to_replace` parameter is set. But even if we
      tell it to replace such entries, it will return an error code.
      
      Fix the error by returning success in case where the entries have been
      replaced. Fix an already existing test which tested for wrong behaviour.
      Note that the test didn't notice that the resulting tree had no entries.
      Thus it is fine to change existing behaviour here, as the previous
      result could've let to silently loosing data. Also add a new test that
      verifies behaviour in the reverse conflicting case.
      Patrick Steinhardt committed
  12. 08 Oct, 2018 1 commit
  13. 24 Aug, 2018 1 commit
  14. 13 Jul, 2018 1 commit
    • treewide: remove use of C++ style comments · 9994cd3f
      C++ style comment ("//") are not specified by the ISO C90 standard and
      thus do not conform to it. While libgit2 aims to conform to C90, we did
      not enforce it until now, which is why quite a lot of these
      non-conforming comments have snuck into our codebase. Do a tree-wide
      conversion of all C++ style comments to the supported C style comments
      to allow us enforcing strict C90 compliance in a later commit.
      Patrick Steinhardt committed
  15. 29 Jun, 2018 4 commits
    • settings: optional unsaved index safety · bfa1f022
      Add the `GIT_OPT_ENABLE_UNSAVED_INDEX_SAFETY` option, which will cause
      commands that reload the on-disk index to fail if the current
      `git_index` has changed that have not been saved.  This will prevent
      users from - for example - adding a file to the index then calling a
      function like `git_checkout` and having that file be silently removed
      from the index since it was re-read from disk.
      
      Now calls that would re-read the index will fail if the index is
      "dirty", meaning changes have been made to it but have not been written.
      Users can either `git_index_read` to discard those changes explicitly,
      or `git_index_write` to write them.
      Edward Thomson committed
    • index: return a unique error code on dirty index · 787768c2
      When the index is dirty, return GIT_EINDEXDIRTY so that consumers can
      identify the exact problem programatically.
      Edward Thomson committed
    • index: commit the changes to the index properly · b242cdbf
      Now that the index has a "dirty" state, where it has changes that have
      not yet been committed or rolled back, our tests need to be adapted to
      actually commit or rollback the changes instead of assuming that the
      index can be operated on in its indeterminate state.
      Edward Thomson committed
    • index: test dirty index bit · dc4a18c7
      Test that any changes to the index will mark the index as dirty.  Also
      ensure that when we initialize a new index, read the index contents
      from disk, or write the index contents to disk that we reset the dirty
      flag to zero.  Further ensure that an unforced read with dirty contents
      (when the on-disk index has not changed) does _not_ reset the dirty
      flag as we have not updated the contents of our index and our unsaved
      contents remain intact.
      Edward Thomson committed
  16. 26 Jun, 2018 3 commits
    • index::addall tests: write the index · 7330ae67
      When running `git_index_add_all`, we should write the index to disk so
      that we can re-read it safely during status.
      Edward Thomson committed
    • index::reuc tests: test that checkout succeeds · 08ea0d7d
      The index::reuc tests must test that the checkout itself succeeds,
      otherwise subsequent tests are not valid.
      
      In fact, the checkouts were failing because when checking out `SAFE`,
      they cannot update the files that are in conflict.  Change the checkout
      level to `FORCE` to ensure that they get updated correctly.
      Edward Thomson committed
    • index::names tests: add conflicts with high stages · c4ce017f
      We add entries into the main index to correspond with the NAME entries
      that we're going to test.  NAME entries store the results of conflicts
      occuring with rename detection during merge, and they must correspond to
      conflicts in the index.
      
      This test was mistakenly adding regular entries.  The checkout
      validation failed, since it requires NAME entries to correspond to
      high-stage (conflict) entries.  Correct the test to actually create
      conflicts.
      Edward Thomson committed
  17. 10 Jun, 2018 1 commit
  18. 19 Feb, 2018 1 commit
    • tests: index::filemodes: fix use of uninitialized memory · cabe16df
      The new index entry structure was not being initialized to all-zeroes.
      As that structure is used to add a new entry to the current index, and
      the hashing algorithm of the index making use of the uninitialized flags
      to calculate the state, we might miscompute the hash of the entry and
      add it at the wrong position. Later lookups would then fail.
      
      Initialize the structure with `memset` to fix the test breaking on some
      platforms.
      Patrick Steinhardt committed
  19. 18 Feb, 2018 1 commit
  20. 23 Jun, 2017 1 commit
    • tests: index::tests: create sandboxed repo for locking · 6ee7d37a
      The test `index::tests::can_lock_index` operates on the "testrepo.git"
      repository located inside of our source tree. While this is okay for
      tests which do read-only operations on these resouces, this specific
      test tries to lock the index by creating a lock. This will obviously
      fail on out-of-tree builds with read-only source trees.
      
      Fix the issue by creating a sandbox first.
      Patrick Steinhardt committed
  21. 06 Jun, 2017 4 commits
    • tests: index::version: improve write test for index v4 · 92d3ea4e
      The current write test does not trigger some edge-cases in the index
      version 4 path compression code. Rewrite the test to start off the an
      empty standard repository, creating index entries with interesting paths
      itself. This allows for more fine-grained control over checked paths.
      Furthermore, we now also verify that entry paths are actually
      reconstructed correctly.
      Patrick Steinhardt committed
    • tests: index::version: verify we write compressed index entries · 8fe33538
      While we do have a test which checks whether a written index of version
      4 has the correct version set, we do not check whether this actually
      enables path compression for index entries. This commit adds a new test
      by adding a number of index entries with equal path prefixes to the
      index and subsequently flushing that to disk. With suffix compression
      enabled by index version 4, only the last few bytes of these paths will
      actually have to be written to the index, saving a lot of disk space.
      For the test, differences are about an order of magnitude, allowing us
      to easily verify without taking a deeper look at actual on-disk
      contents.
      Patrick Steinhardt committed
    • tests: index::version: add test to read index version v4 · 82368b1b
      While we have a simple test to determine whether we can write an index
      of version 4, we never verified that we are able to read this kind of
      index (and in fact, we were not able to do so). Add a new repository
      which has an index of version 4. This repository is then read from a new
      test.
      Patrick Steinhardt committed
    • tests: index::version: move up cleanup function · fea0c81e
      The init and cleanup functions for test suites are usually prepended to
      our actual tests. The index::version test suite does not adhere to this
      stile. Fix this.
      Patrick Steinhardt committed
  22. 29 Aug, 2016 1 commit
  23. 10 Aug, 2016 1 commit
  24. 06 Aug, 2016 1 commit
  25. 29 Jun, 2016 1 commit
  26. 02 Jun, 2016 2 commits