|
13deb874
|
2016-06-07T08:35:26
|
|
index: fix NULL pointer access in index_remove_entry
When removing an entry from the index by its position, we first
retrieve the position from the index's entries and then try to
remove the retrieved value from the index map with
`DELETE_IN_MAP`. When `index_remove_entry` returns `NULL` we try
to feed it into the `DELETE_IN_MAP` macro, which will
unconditionally call `idxentry_hash` and then happily dereference
the `NULL` entry pointer.
Fix the issue by not passing a `NULL` entry into `DELETE_IN_MAP`.
|
|
46082c38
|
2016-06-02T02:34:03
|
|
index_read_index: invalidate new paths in tree cache
When adding a new entry to an existing index via `git_index_read_index`,
be sure to remove the tree cache entry for that new path. This will
mark all parent trees as dirty.
|
|
|
9167c145
|
2016-06-02T01:04:58
|
|
index_read_index: set flags for path_len correctly
Update the flags to reset the path_len (to emulate `index_insert`)
|
|
|
046ec3c9
|
2016-06-02T00:47:51
|
|
index_read_index: differentiate on mode
Treat index entries with different modes as different, which they
are, at least for the purposes of up-to-date calculations.
|
|
|
93de20b8
|
2016-06-01T14:56:27
|
|
index_read_index: reset error correctly
Clear any error state upon each iteration. If one of the iterations
ends (with an error of `GIT_ITEROVER`) we need to reset that error to 0,
lest we stop the whole process prematurely.
|
|
|
f80852af
|
2016-05-02T14:30:14
|
|
index: fix memory leak on error case
|
|
60a194aa
|
2016-03-20T11:00:12
|
|
tree: re-use the id and filename in the odb object
Instead of copying over the data into the individual entries, point to
the originals, which are already in a format we can use.
|
|
|
80a834a5
|
2016-03-01T16:00:49
|
|
index: assert required OID are non-NULL
|
|
|
6ddf533a
|
2016-02-23T18:29:16
|
|
git_index_add: validate objects in index entries (optionally)
When `GIT_OPT_ENABLE_STRICT_OBJECT_CREATION` is turned on, validate
the index entries given to `git_index_add`.
|
|
9f4e7c84
|
2016-02-25T18:42:09
|
|
Merge pull request #3638 from ethomson/nsec
USE_NSECS fixes
|
|
|
3d6a42d1
|
2016-02-25T11:23:19
|
|
nsec: support NDK's crazy nanoseconds
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).
|
|
|
0f1e2d20
|
2016-02-23T11:23:26
|
|
index: fix contradicting comparison
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.
|
|
|
7808c937
|
2016-02-22T15:59:15
|
|
index: plug memory leak in `read_conflict_names`
|
|
|
5663d4f6
|
2016-02-18T12:31:56
|
|
Merge pull request #3613 from ethomson/fixups
Remove most of the silly warnings
|
|
|
594a5d12
|
2016-02-18T12:28:06
|
|
Merge pull request #3619 from ethomson/win32_forbidden
win32: allow us to read indexes with forbidden paths on win32
|
|
|
318b825e
|
2016-02-16T17:11:46
|
|
index: allow read of index w/ illegal entries
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`).
|
|
|
b2ca8d9c
|
2016-02-12T10:22:54
|
|
index: explicitly cast the teeny index entry members
|
|
|
997e0301
|
2016-02-12T10:11:32
|
|
index: don't use `seek` return as an error code
|
|
|
9a634cba
|
2016-02-12T10:03:29
|
|
index: explicitly cast new hash size to an int
|
|
3679ebae
|
2016-02-11T23:37:52
|
|
Horrible fix for #3173.
|
|
|
9d81509a
|
2015-12-23T11:54:52
|
|
index: get rid of the locking
We don't support using an index object from multiple threads at the same
time, so the locking doesn't have any effect when following the
rules. If not following the rules, things are going to break down
anyway.
|
|
ef8b7feb
|
2015-12-16T19:36:50
|
|
index: Also size-hint the hash table
Note that we're not checking whether the resize succeeds; in OOM cases,
we let it run with a "small" vector and hash table and see if by chance
we can grow it dynamically as we insert the new entries. Nothing to
lose really.
|
|
|
d7d46cfb
|
2015-12-16T17:00:25
|
|
index: Preallocate the entries vector with size hint
|
|
|
0cc20a8c
|
2015-12-16T16:53:06
|
|
index: Adjust namemask & mode when filling
|
|
|
879ebab3
|
2015-12-16T12:30:52
|
|
merge: Use `git_index__fill` to populate the index
Instead of calling `git_index_add` in a loop, use the new
`git_index_fill` internal API to fill the index with the initial staged
entries.
The new `fill` helper assumes that all the entries will be unique and
valid, so it can append them at the end of the entries vector and only
sort it once at the end. It performs no validation checks.
This prevents the quadratic behavior caused by having to sort the
entries list once after every insertion.
|
|
|
dc49eb58
|
2015-12-10T11:57:44
|
|
Merge pull request #3538 from pks-t/pks/index-memory-leak
index: always queue `remove_entry` for removal
|
|
|
b057fdef
|
2015-12-08T16:00:35
|
|
index: always queue `remove_entry` for removal
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.
|
|
626f9e24
|
2015-12-03T16:27:15
|
|
index: canonicalize inserted paths safely
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.
|
|
25e84f95
|
2015-11-23T15:49:54
|
|
checkout: only consider nsecs when built that way
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).
|
|
|
5f32c506
|
2015-11-16T18:06:52
|
|
racy: make git_index_read_index handle raciness
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.
|
|
|
27bc41cf
|
2015-11-13T16:31:51
|
|
index: clear uptodate bit on save
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.
|
|
|
d1101263
|
2015-11-13T15:32:48
|
|
index: don't detect raciness in uptodate entries
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.
|
|
|
cb0ff012
|
2015-11-06T17:15:35
|
|
racy-git: do a single index->workdir diff
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.
|
|
|
75a0ccf5
|
2015-11-12T19:53:09
|
|
Merge pull request #3170 from CmdrMoozy/nsec_fix
git_index_entry__init_from_stat: set nsec fields in entry stats
|
|
|
ad8509ef
|
2015-11-12T11:54:06
|
|
index: overwrite the path when inserting conflicts
When we insert a conflict in a case-insensitive index, accept the
new entry's path as the correct case instead of leaving the path we
already had.
This puts `git_index_conflict_add()` on the same level as
`git_index_add()` in this respect.
|
|
|
16604d74
|
2015-11-11T00:36:15
|
|
index: correctly report which conflict stage has a wrong filemode
When we're at offset 'i', we're dealing with the 'i+1' stage, since
conflicts start at 1.
|
|
|
0bf77e32
|
2015-10-30T13:07:02
|
|
index: read_index must update hashes
|
|
|
1e5e02b4
|
2015-10-27T17:26:04
|
|
pool: Simplify implementation
|
|
|
d307a013
|
2015-10-27T22:17:32
|
|
reuc: Be smarter when inserting new REUC entries
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.
|
|
|
128e94bb
|
2015-10-21T12:04:53
|
|
index: Remove unneeded consts
|
|
|
21515f22
|
2015-09-29T15:49:16
|
|
index: also try conflict mode when inserting
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.
|
|
0226f7dd
|
2015-08-29T13:59:20
|
|
diff/index: respect USE_NSEC for racily clean file detection
|
|
|
e9e6df2c
|
2015-06-15T09:28:55
|
|
cmake: Only provide USE_NSEC if struct stat members are avilable.
This allows us to remove OS checks from source code, instead relying
on CMake to detect whether or not `struct stat` has the nanoseconds
members we rely on.
|
|
|
e7de893e
|
2015-06-01T13:43:54
|
|
cmake: add USE_NSEC, and only check nanosec m/ctime if enabled
|
|
|
6d6020de
|
2015-09-08T18:34:51
|
|
Merge pull request #3353 from ethomson/wrongcase_add
index: canonicalize directory case when adding
|
|
|
2964cbea
|
2015-09-08T11:50:08
|
|
Merge pull request #3381 from leoyanggit/index_directory_iterator
New feature: add the ablility to iterate through a directory in index
|
|
|
a32bc85e
|
2015-08-07T12:43:49
|
|
git_index_add: allow case changing renames
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.
|
|
|
280adb3f
|
2015-08-04T16:51:00
|
|
index: canonicalize directory case when adding
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`.
|
|
|
9fd4c9c8
|
2015-09-06T10:50:22
|
|
Merge pull request #3366 from libgit2/cmn/index-hashmap
Use a hashmap for path-based lookups in the index
|
|
c097f717
|
2015-08-17T15:02:02
|
|
New API: git_index_find_prefix
Find the first index entry matching a prefix.
|
|
|
81b76367
|
2015-09-04T13:30:49
|
|
index: put the icase insert choice in macros
This should let us see more clearly what we're doing and avoid the ugly
'if' we need every time we want to interact with the map.
|
|
|
810cabb9
|
2015-07-28T20:04:11
|
|
racy-git: TODO to use improved diffing
|
|
|
ed1c6446
|
2015-07-28T11:41:27
|
|
iterator: use an options struct instead of args
|
|
|
af1d5239
|
2015-08-14T21:10:12
|
|
index: keep a hash table as well as a vector of entries
The hash table allows quick lookup of specific paths, while we use the
vector for enumeration.
|
|
|
ef4857c2
|
2015-08-03T16:50:27
|
|
errors: tighten up git_error_state OOMs a bit more
When an error state is an OOM, make sure that we treat is specially
and do not try to free it.
|
|
|
ea961abf
|
2015-08-01T19:53:53
|
|
index: stage an unregistered submodule as well
We previously added logic to `_add_bypath()` to update a submodule. Go
further and stage the submodule even if it's not registered to behave
like git.
|
|
|
247d27c2
|
2015-07-11T19:41:03
|
|
index: allow add_bypath to update submodules
Similarly to how git itself does it, allow the index update operation to
stage a change in a submodule's HEAD.
|
|
|
74975846
|
2015-06-18T14:22:10
|
|
index: check racily clean entries more thoroughly
When an entry has a racy timestamp, we need to check whether the file
itself has changed since we put its entry in the index. Only then do we
smudge the size field to force a check the next time around.
|
|
|
624c949f
|
2015-06-20T16:17:28
|
|
index: make relative comparison use the checksum as well
This is used by the submodule in order to figure out if the index has
changed since it last read it. Using a timestamp is racy, so let's make
it use the checksum, just like we now do for reloading the index itself.
|
|
|
5e947c91
|
2015-06-19T22:05:08
|
|
index: use the checksum to check whether it's been modified
We currently use a timetamp to check whether an index file has been
modified since we last read it, but this is racy. If two updates happen
in the same second and we read after the first one, we won't detect the
second one.
Instead read the SHA-1 checksum of the file, which are its last 20 bytes which
gives us a sure-fire way to detect whether the file has changed since we
last read it.
As we're now keeping track of it, expose an accessor to this data.
|
|
|
316b820b
|
2015-06-15T09:55:40
|
|
index: zero the size of racily-clean entries
If a file entry has the same timestamp as the index itself, it is
considered racily-clean, as it may have been modified after the index
was written, but during the same second. We take extra steps to check
the contents, but this is just one part of avoiding races.
For files which do have changes but have not been updated in the index,
updating the on-disk index means updating its timestamp, which means we
would no longer recognise these entries as racy and we would trust the
timestamp to tell us whether they have changed.
In order to work around this, git zeroes out the file-size field in
entries with the same timestamp as the index in order to force the next
diff to check the contents. Do so in libgit2 as well.
|
|
|
8147b1af
|
2015-05-25T20:03:59
|
|
diff: introduce binary diff callbacks
Introduce a new binary diff callback to provide the actual binary
delta contents to callers. Create this data from the diff contents
(instead of directly from the ODB) to support binary diffs including
the workdir, not just things coming out of the ODB.
|
|
|
9b3e41f7
|
2015-05-19T18:29:15
|
|
index_add_all: remove conflicts when no wd file
If there exists a conflict in the index, but no file in the working
directory, this implies that the user wants to accept the resolution
by removing the file. Thus, remove the conflict entry from the
index, instead of trying to add a (nonexistent) file.
|
|
|
9f545b9d
|
2015-05-19T11:23:59
|
|
introduce `git_index_entry_is_conflict`
It's not always obvious the mapping between stage level and
conflict-ness. More importantly, this can lead otherwise sane
people to write constructs like `if (!git_index_entry_stage(entry))`,
which (while technically correct) is unreadable.
Provide a nice method to help avoid such messy thinking.
|
|
|
d67f270e
|
2015-05-14T13:30:29
|
|
index: validate mode of new conflicts
|
|
|
3ab5a659
|
2015-05-14T12:54:39
|
|
index: remove error message in non-error remove
If `git_index_remove_bypath` does no work, and returns an OK error
code, it should not set an error message.
|
|
|
ecd60a56
|
2015-05-14T11:52:48
|
|
conflicts: when adding conflicts, remove staged
When adding a conflict for some path, remove the staged entry.
Otherwise, an illegal index (with both stage 0 and high-stage
entries) would result.
|
|
|
cbfeecf3
|
2015-05-20T20:13:45
|
|
git_index_add_all: don't recurse ignored dirs
No need to get reports about individual ignored files, having a
single ignored directory delta is enough.
|
|
|
fa9a969d
|
2015-05-20T18:22:17
|
|
index_add_all: include untracked files in new subdirs
|
|
|
2b2dfe80
|
2015-05-12T12:07:33
|
|
index: include TYPECHANGE in the diff
Without this option, we would not be able to catch exec bit changes.
|
|
|
0a78a52e
|
2015-05-11T16:09:09
|
|
index: make add_all to act on a diff
Instead of going through each entry we have and re-adding, which may not
even be correct for certain crlf options and has bad performance, use
the function which performs a diff against the worktree and try to add
and remove files from that list.
|
|
|
197307f6
|
2015-05-11T15:19:15
|
|
index: refactor diff-based update_all to match other applies
Refactor so we look like the code we're replacing, which should also
allow us to more easily inplement add-all.
|
|
|
713e11e0
|
2015-05-11T13:24:53
|
|
index: use a diff to perform update_all
We currently iterate over all the entries and re-add them to the
index. While this provides correctness, it is wasteful as we try to
re-insert files which have not changed.
Instead, take a diff between the index and the worktree and only re-add
those which we already know have changed.
|
|
|
35d39761
|
2015-03-18T00:25:18
|
|
index: introduce git_index_read_index
|
|
d3282680
|
2015-04-20T23:41:04
|
|
Fix index-adding functions to know when to trust filemodes.
The idea...sometimes, a filemode is user-specified via an
explicit git_index_entry. In this case, believe the user, always.
Sometimes, it is instead built up by statting the file system. In
those cases, go with the existing logic we have to determine
whether the file system supports all filemodes and symlinks, and
make the best guess.
On file systems which have full filemode and symlink support, this
commit should make no difference. On others (most notably Windows),
this will fix problems things like:
* git_index_add and git_index_add_frombuffer() should be believed.
* As a consequence, git_checkout_tree should make the filemodes in
the index match the ones in the tree.
* And diffs with GIT_DIFF_UPDATE_INDEX don't write the wrong filemodes.
* And merges, and probably other downstream stuff now fixed, too.
This makes my previous changes to checkout.c unnecessary,
so they are now reverted.
Also, added a test for index_entry permissions from git_index_add
and git_index_add_frombuffer, both of which failed before these changes.
|
|
807566d5
|
2015-04-03T18:59:11
|
|
Entry argument passed to git_index_add_frombuffer() should be const
|
|
a275fbc0
|
2015-02-05T11:40:16
|
|
Add API to add a memory buffer to an index
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.
|
|
|
a291790a
|
2015-02-15T05:18:01
|
|
Merge pull request #2831 from ethomson/merge_lock
merge: lock index during the merge (not just checkout)
|
|
|
41fae48d
|
2015-02-03T22:31:10
|
|
indexwriter: an indexwriter for repo operations
Provide git_indexwriter_init_for_operation for the common locking
pattern in merge, rebase, revert and cherry-pick.
|
|
|
55798fd1
|
2015-01-17T20:49:04
|
|
git_indexwriter: lock then write the index
Introduce `git_indexwriter`, to allow us to lock the index while
performing additional operations, then complete the write (or abort,
unlocking the index).
|
|
|
f1453c59
|
2015-02-12T12:19:37
|
|
Make our overflow check look more like gcc/clang's
Make our overflow checking look more like gcc and clang's, so that
we can substitute it out with the compiler instrinsics on platforms
that support it. This means dropping the ability to pass `NULL` as
an out parameter.
As a result, the macros also get updated to reflect this as well.
|
|
|
2884cc42
|
2015-02-11T09:39:38
|
|
overflow checking: don't make callers set oom
Have the ALLOC_OVERFLOW testing macros also simply set_oom in the
case where a computation would overflow, so that callers don't
need to.
|
|
|
392702ee
|
2015-02-09T23:41:13
|
|
allocations: test for overflow of requested size
Introduce some helper macros to test integer overflow from arithmetic
and set error message appropriately.
|
|
b63b3b0e
|
2015-01-25T14:08:05
|
|
Ensure git_index_entry is not NULL before trying to free it
|
|
|
2fe8157e
|
2014-12-22T18:42:03
|
|
index: reuc and name entrycounts should be size_t
For the REUC and NAME entries, we use size_t internally, and we take
size_t for the get_byindex() functions, but the entrycount() functions
strangely cast to an unsigned int instead.
|
|
|
a64119e3
|
2014-11-25T18:13:00
|
|
checkout: disallow bad paths on win32
Disallow:
1. paths with trailing dot
2. paths with trailing space
3. paths with trailing colon
4. paths that are 8.3 short names of .git folders ("GIT~1")
5. paths that are reserved path names (COM1, LPT1, etc).
6. paths with reserved DOS characters (colons, asterisks, etc)
These paths would (without \\?\ syntax) be elided to other paths - for
example, ".git." would be written as ".git". As a result, writing these
paths literally (using \\?\ syntax) makes them hard to operate with from
the shell, Windows Explorer or other tools. Disallow these.
|
|
|
0d388adc
|
2014-11-25T00:58:03
|
|
index: Check for valid paths before creating an index entry
|
|
|
62a617dc
|
2014-11-06T16:16:46
|
|
iterator: submodules are determined by an index or tree
We cannot know from looking at .gitmodules whether a directory is a
submodule or not. We need the index or tree we are comparing against to
tell us. Otherwise we have to assume the entry in .gitmodules is stale
or otherwise invalid.
Thus we pass the index of the repository into the workdir iterator, even
if we do not want to compare against it. This follows what git does,
which even for `git diff <tree>`, it will consider staged submodules as
such.
|
|
|
c2f8b215
|
2014-09-28T07:00:49
|
|
index: write out the tree cache extension
Keeping the cache around after read-tree is only one part of the
optimisation opportunities. In order to share the cache between program
instances, we need to write the TREE extension to the index.
Do so, taking the opportunity to rename 'entries' to 'entry_count' to
match the name given in the format description. The included test is
rather trivial, but works as a sanity check.
|
|
|
6843cebe
|
2014-07-10T14:10:39
|
|
index: fill the tree cache when reading from a tree
When reading from a tree, we know what every tree is going to look like,
so we can fill in the tree cache completely, making use of the index for
modification of trees a lot quicker.
|
|
|
19c88310
|
2014-07-10T13:48:13
|
|
tree-cache: move to use a pool allocator
This simplifies freeing the entries quite a bit; though there aren't
that many failure paths right now, introducing filling the cache from a
tree will introduce more. This makes sure not to leak memory on errors.
|
|
|
ff97778a
|
2014-09-25T13:07:36
|
|
The raw index buffer content is not guaranteed to be aligned
* Ensure alignment by copying the content into a structure on the stack
|
|
|
052a2ffd
|
2014-05-22T16:01:02
|
|
index: check for valid filemodes on add
|
|
0fc8e1f6
|
2014-04-28T14:34:55
|
|
Lay groundwork for updating stat cache in diff
This reorganized the diff OID calculation to make it easier to
correctly update the stat cache during a diff once the flags to
do so are enabled.
This includes marking the path of a git_index_entry as const so
we can make a "fake" git_index_entry with a "const char *" path
and not get warnings. I was a little surprised at how unobtrusive
this change was, but I think it's probably a good thing.
|
|
|
17ef678c
|
2014-04-21T11:55:57
|
|
Fix some coverity-found issues
|
|
|
ea642d61
|
2014-04-14T12:29:27
|
|
Fix race checking for existing index items
In the threading tests, I was still seeing a race condition where
the same item could end up being inserted multiple times into the
index. Preserving the sorted-ness of the index outside of the
`index_insert` call fixes the issue.
|
|
|
7d490872
|
2014-04-10T22:31:01
|
|
Attribute file cache refactor
This is a big refactoring of the attribute file cache to be a bit
simpler which in turn makes it easier to enforce a lock around any
updates to the cache so that it can be used in a threaded env.
Tons of changes to the attributes and ignores code.
|
|
|
aba6b5ed
|
2014-03-14T21:59:26
|
|
Fix leak in git_index_conflict_cleanup
I introduced a leak into conflict cleanup by removing items from
inside the git_vector_remove_matching call. This simplifies the
code to just use one common way for the two conflict cleanup APIs.
When an index has an active snapshot, removing an item can cause
an error (inserting into the deferred deletion vector), so I made
the git_index_conflict_cleanup API return an error code. I felt
like this wasn't so bad since it is just like the other APIs.
I fixed up a couple of comments while I was changing the header.
|
|
|
52bb0476
|
2014-03-14T13:53:15
|
|
Clean up index snapshot function naming
Clear up some of the various "find" functions and the snapshot
API naming to be things I like more.
|
|
|
8a2834d3
|
2014-03-14T13:20:51
|
|
Index locking and entry allocation changes
This makes the lock management on the index a little bit broader,
having a number of routines hold the lock across looking up the
item to be modified and actually making the modification. Still
not true thread safety, but more pure index modifications are now
safe which allows the simple cases (such as starting up a diff
while index modifications are underway) safe enough to get the
snapshot without hitting allocation problems.
As part of this, I simplified the allocation of index entries to
use a flex array and just put the path at the end of the index
entry. This makes every entry self-contained and makes it a
little easier to feel sure that pointers to strings aren't
being accidentally copied and freed while other references are
still being held.
|