| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
