| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Like we want to separate libgit2 and utility source code, we want to
separate libgit2 and utility tests. Start by moving all the tests into
libgit2.
|
| | |
|
| |
|
|
|
|
| |
Introduce `git_fs_path`, which operates on generic filesystem paths.
`git_path` will be kept for only git-specific path functionality (for
example, checking for `.git` in a path).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libgit2 has two distinct requirements that were previously solved by
`git_buf`. We require:
1. A general purpose string class that provides a number of utility APIs
for manipulating data (eg, concatenating, truncating, etc).
2. A structure that we can use to return strings to callers that they
can take ownership of.
By using a single class (`git_buf`) for both of these purposes, we have
confused the API to the point that refactorings are difficult and
reasoning about correctness is also difficult.
Move the utility class `git_buf` to be called `git_str`: this represents
its general purpose, as an internal string buffer class. The name also
is an homage to Junio Hamano ("gitstr").
The public API remains `git_buf`, and has a much smaller footprint. It
is generally only used as an "out" param with strict requirements that
follow the documentation. (Exceptions exist for some legacy APIs to
avoid breaking callers unnecessarily.)
Utility functions exist to convert a user-specified `git_buf` to a
`git_str` so that we can call internal functions, then converting it
back again.
|
| |
|
|
|
|
| |
We should always verify error codes returned by function calls in our
test suite to not accidentally miss any weird results. Coverity reported
missing checks in several locations, which this commit fixes.
|
| |
|
|
|
| |
Users may want to turn off core.protectNTFS, perhaps to import (and then
repair) a broken tree. Ensure that core.protectNTFS=false is honored.
|
| |
|
|
|
| |
Enable core.protectNTFS by default everywhere and in every codepath, not
just on checkout.
|
| |
|
|
|
| |
Test that when we enable core.protectNTFS that we cannot add
platform-specific invalid paths to the index.
|
| |
|
|
|
|
| |
The name of the `add_invalid_filename` function suggests that we
_want_ to add an invalid filename. Rename the function to show that
we expect to _fail_ to add the invalid filename.
|
| |
|
|
|
| |
Ensure that the new protection around .git::$INDEX_ALLOCATION rules are
enabled for adding to the index when core.protectNTFS is set.
|
| |
|
|
|
|
| |
The name of the `write_invalid_filename` function suggests that we
_want_ to write an invalid filename. Rename the function to show that
we expect to _fail_ to write the invalid filename.
|
| |
|
|
| |
Prefer `off64_t` internally.
|
| |
|
|
|
|
| |
The majority of functions are named `from_something` (with an
underscore) instead of `fromsomething`. Update the index functions for
consistency with the rest of the library.
|
| |
|
|
|
| |
Move to the `git_error` name in the internal API for error-related
functions.
|
| |
|
|
| |
Use the new-style index names throughout our own codebase.
|
| |
|
|
|
|
| |
Provide a public git_index_iterator API that is backed by an index
snapshot. This allows consumers to provide a stable iteration even
while manipulating the index during iteration.
|
| |
|
|
|
|
|
|
|
|
| |
When the index does not belong to any repository, we do not do any checks of the
target id going in as we cannot verify that it exists.
When we then write it out to a repository as a tree, we fail to perform the
object existance and type-matching check that we do in other code-paths. This
leads to being able to write trees which point to non-existent blobs even with
strict object creation enabled.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
When the index is dirty, return GIT_EINDEXDIRTY so that consumers can
identify the exact problem programatically.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Untangle git_futils_mkdir from git_futils_mkdir_ext - the latter
assumes that we own everything beneath the base, as if it were
being called with a base of the repository or working directory,
and is tailored towards checkout and ensuring that there is no
bogosity beneath the base that must be cleaned up.
This is (at best) slow and (at worst) unsafe in the larger context
of a filesystem where we do not own things and cannot do things like
unlink symlinks that are in our way.
|
| |\
| |
| | |
New feature: add the ablility to iterate through a directory in index
|
| | |
| |
| |
| | |
Find the first index entry matching a prefix.
|
| |/
|
|
|
| |
We were missing tests for switching the case-sensitivity of an index
in-memory and then looking up entries in it.
|
| |
|
|
|
| |
This will tell us which numbers we were trying to compare, rather than
just telling us that they're different.
|
| |
|
|
|
|
| |
git_index_add_frombuffer enables now to store a memory buffer in the odb
and to store an entry in the index directly if the index is attached to a
repository.
|
| |
|
|
|
|
| |
Introduce `git_indexwriter`, to allow us to lock the index while
performing additional operations, then complete the write (or abort,
unlocking the index).
|
| | |
|
| | |
|
| |
|
|
|
| |
We need these directories to exist so cl_git_mkfile() can create the
files we ask it to.
|
| |
|
|
|
|
| |
Path validation may be influenced by `core.protectHFS` and
`core.protectNTFS` configuration settings, thus treebuilders
can take a repository to influence their configuration.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This is just laying some groundwork for internal index changes
that I'm working on.
|
| |
|
|
|
|
|
| |
This fixes a typo I made for setting the sorted flag on the index
after a reload. That typo didn't actually cause any test failures
so I'm also adding a test that explicitly checks that the index is
correctly sorted after a reload when ignoring case and when not.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This updates the git_pqueue to simply be a set of specialized
init/insert/pop functions on a git_vector.
To preserve the pqueue feature of having a fixed size heap, I
converted the "sorted" field in git_vectors to a more general
"flags" field so that pqueue could mix in it's own flag. This
had a bunch of ramifications because a number of places were
directly looking at the vector "sorted" field - I added a couple
new git_vector helpers (is_sorted, set_sorted) so the specific
representation of this information could be abstracted.
|
| |
|
|
| |
This was not converted when we converted the rest, so do it now.
|
| | |
|
| | |
|
| |
|
