| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This adds a `-Wunused-result`-proof `GIT_UNUSED()`, just to demonstrate
that it works. With this, sortedcache.h is now completely
`GIT_WARN_UNUSED_RESULT`-annotated!
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The `git_index_free()` merely decrement the reference counter from 2 to
1, and does not "free" the index.
Thus, the following `git_repository_index()` merely increase the counter
to 2, instead of read index from disk.
The written index is not read and parsed, which makes this test case
effectively becomes a no-op.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Our file utils functions all have a "futils" prefix, e.g.
`git_futils_touch`. One would thus naturally guess that their
definitions and implementation would live in files "futils.h" and
"futils.c", respectively, but in fact they live in "fileops.h".
Rename the files to match expectations.
|
| |
|
|
|
| |
`cvar` is an unhelpful name. Refactor its usage to `configmap` for more
clarity.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
Cast actual filesystem data to the int32_t that index entries store.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Move to the `git_error` name in the internal API for error-related
functions.
|
| |\
| |
| | |
Fix a bunch of warnings
|
| | | |
|
| | |
| |
| |
| | |
It seems like MingW64's size_t is defined differently than in Linux.
|
| | |
| |
| |
| |
| | |
This change fixes -Wmaybe-uninitialized and -Wdeprecated-declarations
warnings on Linux builds
|
| |/
|
| |
CID 1398597, 1398598
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a cherry-pick of the tests from the following commits:
core.autocrlf=true and core.safecrlf=true did not fail on LF-only file as vanilla git does
Adding a CRLF-file with core.autocrlf=input and core.safecrlf=true does not fail as with vanilla git
Make files with #CR!=#CRLF not fail with core.safecrlf=true
Reported-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw>
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
| |
|
|
|
|
|
| |
Don't simply fail when the expected output does not match the data in
the index; instead, provide a detailed output about the system, file,
and settings that caused the failure so that developers can better
isolate the problem(s).
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Given a variety of combinations of core.autocrlf, core.safecrlf settings
and attributes settings, test that we add files to index the same way
(regarding OIDs and fatal errors) as a known-good test resource created
by git.git.
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
| |
|
|
| |
Use the new object_type enumeration names within the codebase.
|
| |
|
|
| |
Use the new-style index names throughout our own codebase.
|
| |\
| |
| | |
index: introduce git_index_iterator
|
| | |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| |/
|/| |
Index collision fixes
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Commit 581d5492f (Fix leak in index.c, 2018-08-16) was fixing a memory
leak in our code adding conflicts to the index when the added index
entries have an invalid file mode. The memory leak was previously
undiscovered as there are no tests covering this scenario, which is now
being added by this commit.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
When running `git_index_add_all`, we should write the index to disk so
that we can re-read it safely during status.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Ensure that the buffer given to `git_index_add_frombuffer` represents a
regular blob, an executable blob, or a link. Explicitly reject commit
entries (submodules) - it makes little sense to allow users to add a
submodule from a string; there's no possible path to success.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|