| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| | |
Index fill: Small fixups
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| |\ \
| |/
|/| |
fix git_blob_create_fromchunks documentation
|
| | |
| |
| | |
putting `0.` at the start of the line turns it into a numbered list.
|
| |\ \
| |/
|/| |
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.
|
| |\
| |
| | |
Treat GIT_PASSTHROUGH as though git_cred_acquire_cb isn't set.
|
| | | |
|
| |\ \
| | |
| | | |
Line count overflow in git_blame_hunk and git_blame__entry
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The `git_blame__entry` struct keeps track of line counts with
`int` fields. Since `int` is only guaranteed to be at least 16
bits we may overflow on certain platforms when line counts exceed
2^15.
Fix this by instead storing line counts in `size_t`.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It is not unreasonable to have versioned files with a line count
exceeding 2^16. Upon blaming such files we fail to correctly keep
track of the lines as `git_blame_hunk` stores them in `uint16_t`
fields.
Fix this by converting the line fields of `git_blame_hunk` to
`size_t`. Add test to verify behavior.
|
| |\ \ \
| | | |
| | | | |
diff: include commit message when formatting patch
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When formatting a patch as email we do not include the commit's
message in the formatted patch output. Implement this and add a
test that verifies behavior.
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It is already possible to get a commit's summary with the
`git_commit_summary` function. It is not possible to get the
remaining part of the commit message, that is the commit
message's body.
Fix this by introducing a new function `git_commit_body`.
|
| |\ \ \
| | | |
| | | | |
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.
|
| |\ \ \
| | | |
| | | | |
reset: perform the checkout before moving HEAD or the index
|
| |/ / /
| | |
| | |
| | |
| | |
| | | |
This keeps the state of the workdir the same as one from HEAD, removing
a source of possible confusion when calculating the work that is to be
done.
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Use a typedef for the submodule_foreach callback.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This fits with the style for the rest of the project, but more
importantly, makes life easier for bindings authors who auto-generate
code.
|
| |\ \ \ \
| |/ / /
|/| | | |
tree: mark a tree as already sorted
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The trees are sorted on-disk, so we don't have to go over them
again. This cuts almost a fifth of time spent parsing trees.
|
| |\ \ \ \
| | | | |
| | | | | |
CMakeLists: Compare CMAKE_SIZEOF_VOID_P as a number, not as a string
|
| | | |/ /
| |/| | |
|
| |\ \ \ \
| |_|/ /
|/| | | |
checkout test: Apply umask to file-mode test as well
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix the file-mode test to expect system umask being applied to the
created file as well (it is currently applied to the directory only).
This fixes the test on systems where umask != 022.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
| |\ \ \
| | | |
| | | | |
tree: use a specialised mode parse function
|
| | |/ /
| | |
| | |
| | |
| | | |
Instead of going out to strtol, which is made to parse generic numbers,
copy a parse function from git which is specialised for file modes.
|
| |\ \ \
| |/ /
|/| | |
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.
|
| |\ \
| |/
|/| |
tree: mark cloned tree entries as un-pooled
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
When duplicating a `struct git_tree_entry` with
`git_tree_entry_dup` the resulting structure is not allocated
inside a memory pool. As we do a 1:1 copy of the original struct,
though, we also copy the `pooled` field, which is set to `true`
for pooled entries. This results in a huge memory leak as we
never free tree entries that were duplicated from a pooled
tree entry.
Fix this by marking the newly duplicated entry as un-pooled.
|
| |\
| |
| | |
Improvements to tree parsing speed
|
| | |
| |
| |
| |
| |
| | |
Return an error in case the length is too big. Also take this
opportunity to have a single allocating function for the size and
overflow logic.
|
| | |
| |
| |
| |
| |
| | |
This reduces the size of the struct from 32 to 26 bytes, and leaves a
single padding byte at the end of the struct (which comes from the
zero-length array).
|
| | |
| |
| |
| |
| | |
We already know the size due to the `memchr()` so use that information
instead of calling `strlen()` on it.
|
| | |
| |
| |
| |
| |
| |
| | |
These are rather small allocations, so we end up spending a non-trivial
amount of time asking the OS for memory. Since these entries are tied to
the lifetime of their tree, we can give the tree a pool so we speed up
the allocations.
|
| | |
| |
| |
| |
| |
| |
| | |
We've already looked at the filename with `memchr()` and then used
`strlen()` to allocate the entry. We already know how much we have to
advance to get to the object id, so add the filename length instead of
looking at each byte again.
|
| |\ \
| | |
| | | |
Compiler warning fixes
|
| | | | |
|
| |/ / |
|
| |\ \
| |/
|/| |
Recursive Merge
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When building a recursive merge base, allow conflicts to occur.
Use the file (with conflict markers) as the common ancestor.
The user has already seen and dealt with this conflict by virtue
of having a criss-cross merge. If they resolved this conflict
identically in both branches, then there will be no conflict in the
result. This is the best case scenario.
If they did not resolve the conflict identically in the two branches,
then we will generate a new conflict. If the user is simply using
standard conflict output then the results will be fairly sensible.
But if the user is using a mergetool or using diff3 output, then the
common ancestor will be a conflict file (itself with diff3 output,
haha!). This is quite terrible, but it matches git's behavior.
|
| | | |
|
