|
6f4d04b5
|
2018-03-08T12:36:46
|
|
index: error out on unreasonable prefix-compressed path lengths
When computing the complete path length from the encoded
prefix-compressed path, we end up just allocating the complete path
without ever checking what the encoded path length actually is. This can
easily lead to a denial of service by just encoding an unreasonable long
path name inside of the index. Git already enforces a maximum path
length of 4096 bytes. As we also have that enforcement ready in some
places, just make sure that the resulting path is smaller than
GIT_PATH_MAX.
Reported-by: Krishna Ram Prakash R <krp@gtux.in>
Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>
|
|
|
6ddd286e
|
2018-03-08T12:00:27
|
|
index: fix out-of-bounds read with invalid index entry prefix length
The index format in version 4 has prefix-compressed entries, where every
index entry can compress its path by using a path prefix of the previous
entry. Since implmenting support for this index format version in commit
5625d86b9 (index: support index v4, 2016-05-17), though, we do not
correctly verify that the prefix length that we want to reuse is
actually smaller or equal to the amount of characters than the length of
the previous index entry's path. This can lead to a an integer underflow
and subsequently to an out-of-bounds read.
Fix this by verifying that the prefix is actually smaller than the
previous entry's path length.
Reported-by: Krishna Ram Prakash R <krp@gtux.in>
Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>
|
|
|
b6756821
|
2018-03-08T11:49:19
|
|
index: convert `read_entry` to return entry size via an out-param
The function `read_entry` does not conform to our usual coding style of
returning stuff via the out parameter and to use the return value for
reporting errors. Due to most of our code conforming to that pattern, it
has become quite natural for us to actually return `-1` in case there is
any error, which has also slipped in with commit 5625d86b9 (index:
support index v4, 2016-05-17). As the function returns an `size_t` only,
though, the return value is wrapped around, causing the caller of
`read_tree` to continue with an invalid index entry. Ultimately, this
can lead to a double-free.
Improve code and fix the bug by converting the function to return the
index entry size via an out parameter and only using the return value to
indicate errors.
Reported-by: Krishna Ram Prakash R <krp@gtux.in>
Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>
|
|
|
064a60e9
|
2017-05-19T14:06:15
|
|
index: verify we have enough space left when writing index entries
In our code writing index entries, we carry around a `disk_size`
representing how much memory we have in total and pass this value to
`git_encode_varint` to do bounds checks. This does not make much sense,
as at the time when passing on this variable it is already out of date.
Fix this by subtracting used memory from `disk_size` as we go along.
Furthermore, assert we've actually got enough space left to do the final
path memcpy.
|
|
|
c71dff7e
|
2017-05-19T13:49:34
|
|
index: fix shared prefix computation when writing index entry
When using compressed index entries, each entry's path is preceded by a
varint encoding how long the shared prefix with the previous index entry
actually is. We currently encode a length of `(path_len - same_len)`,
which is doubly wrong. First, `path_len` is already set to `path_len -
same_len` previously. Second, we want to encode the shared prefix rather
than the un-shared suffix length.
Fix this by using `same_len` as the varint value instead.
|
|
|
83e0392c
|
2017-05-19T13:39:05
|
|
index: also sanity check entry size with compressed entries
We have a check in place whether the index has enough data left for the
required footer after reading an index entry, but this was only used for
uncompressed entries. Move the check down a bit so that it is executed
for both compressed and uncompressed index entries.
|
|
|
350d2c47
|
2017-05-19T14:22:35
|
|
index: remove file-scope entry size macros
All index entry size computations are now performed in
`index_entry_size`. As such, we do not need the file-scope macros for
computing these sizes anymore. Remove them and move the `entry_size`
macro into the `index_entry_size` function.
|
|
|
46b67034
|
2017-05-19T13:59:53
|
|
index: don't right-pad paths when writing compressed entries
Our code to write index entries to disk does not check whether the
entry that is to be written should use prefix compression for the path.
As such, we were overallocating memory and added bogus right-padding
into the resulting index entries. As there is no padding allowed in the
index version 4 format, this should actually result in an invalid index.
Fix this by re-using the newly extracted `index_entry_size` function.
|
|
|
29f498e0
|
2017-05-19T13:38:34
|
|
index: move index entry size computation into its own function
Create a new function `index_entry_size` which encapsulates the logic to
calculate how much space is needed for an index entry, whether it is
simple/extended or compressed/uncompressed. This can later be re-used by
our code writing index entries.
|
|
|
8ceb890b
|
2017-05-19T12:35:21
|
|
index: set last written index entry in foreach-entry-loop
The last written disk entry is currently being written inside of the
function `write_disk_entry`. Make behavior a bit more obviously by
instead setting it inside of `write_entries` while iterating all
entries.
|
|
|
11d0be23
|
2017-05-12T10:01:43
|
|
index: set last entry when reading compressed entries
To calculate the path of a compressed index entry, we need to know the
preceding entry's path. While we do actually set the first predecessor
correctly to "", we fail to update this while reading the entries.
Fix the issue by updating `last` inside of the loop. Previously, we've
been passing a double-pointer to `read_entry`, which it didn't update.
As it is more obvious to update the pointer inside the loop itself,
though, we can simply convert it to a normal pointer.
|
|
|
febe8c14
|
2017-05-10T14:27:12
|
|
index: fix confusion with shared prefix in compressed path names
The index version 4 introduced compressed path names for the entries.
From the git.git index-format documentation:
At the beginning of an entry, an integer N in the variable width
encoding [...] is stored, followed by a NUL-terminated string S.
Removing N bytes from the end of the path name for the previous
entry, and replacing it with the string S yields the path name for
this entry.
But instead of stripping N bytes from the previous path's string and
using the remaining prefix, we were instead simply concatenating the
previous path with the current entry path, which is obviously wrong.
Fix the issue by correctly copying the first N bytes of the previous
entry only and concatenating the result with our current entry's path.
|
|
|
8f1ff26b
|
2017-02-02T13:09:32
|
|
idxmap: remove GIT__USE_IDXMAP
|
|
|
f14f75d4
|
2017-02-02T13:08:52
|
|
khash: avoid using `kh_resize` directly
|
|
|
73028af8
|
2017-01-27T14:20:24
|
|
khash: avoid using macro magic to get return address
|
|
909d5494
|
2016-12-29T12:25:15
|
|
giterr_set: consistent error messages
Error messages should be sentence fragments, and therefore:
1. Should not begin with a capital letter,
2. Should not conclude with punctuation, and
3. Should not end a sentence and begin a new one
|
|
65b78ea3
|
2016-11-17T01:08:49
|
|
use `giterr_set_str()` wherever possible
`giterr_set()` is used when it is required to format a string, and since
we don't really require it for this case, it is better to stick to
`giterr_set_str()`.
This also suppresses a warning(-Wformat-security) raised by the compiler.
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
|
|
5625d86b
|
2016-05-17T15:40:32
|
|
index: support index v4
Support reading and writing index v4. Index v4 uses a very simple
compression scheme for pathnames, but is otherwise similar to index v3.
Signed-off-by: David Turner <dturner@twitter.com>
|
|
|
4aaae935
|
2016-07-22T12:53:13
|
|
index: cast to avoid warning
|
|
|
6249d960
|
2016-06-29T17:55:44
|
|
index: include conflicts in `git_index_read_index`
Ensure that we include conflicts when calling `git_index_read_index`,
which will remove conflicts in the index that do not exist in the new
target, and will add conflicts from the new target.
|
|
|
6f7ec728
|
2016-06-29T17:01:47
|
|
index: refactor common `read_index` functionality
Most of `git_index_read_index` is common to reading any iterator.
Refactor it out in case we want to implement `read_tree` in terms of it
in the future.
|
|
|
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.
|