| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Sometimes you want to create a commit but not write it out to the
objectdb immediately. For these cases, provide a new function to
retrieve the buffer instead of having to go through the db.
|
|
|
|
|
|
|
|
| |
Submodules don't exist in the objectdb and the code is making us try to
look for a blob with its commit id, which is obviously not going to
work.
Skip the test if the user wants to insert a submodule.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Use legitimate (existing) object IDs in tests so that we have the
ability to turn on strict object validation when running tests.
|
| |
|
|
|
|
|
| |
When `GIT_OPT_ENABLE_STRICT_OBJECT_CREATION` is turned on, validate
the index entries given to `git_index_add`.
|
|
|
|
|
| |
When `GIT_OPT_ENABLE_STRICT_OBJECT_CREATION` is turned on, validate
the tree and parent ids given to treebuilder insertion.
|
|
|
|
|
| |
When `GIT_OPT_ENABLE_STRICT_OBJECT_CREATION` is turned on, validate
the tree and parent ids given to commit creation functions.
|
|\
| |
| | |
Add a new build flag to disable the pool allocator
|
| |
| |
| |
| | |
git_pool_malloc calls straight to git__malloc
|
| |
| |
| |
| |
| |
| |
| |
| | |
The index::nsec::staging_maintains_other_nanos test was created to
ensure that when we stage an entry when GIT_USE_NSECS is *unset* that
we truncate the index entry and do not persist the (old, invalid)
nanosec values. Ensure that when GIT_USE_NSECS is *set* that we do
not do that, and actually write the correct nanosecond values.
|
| | |
|
|\ \
| | |
| | | |
Remove most of the silly warnings
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Windows defines `timeval` with `long`, which we cannot
sanely cope with. Instead, use a custom timeval struct.
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
win32: allow us to read indexes with forbidden paths on win32
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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`).
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Introduce a repository that contains some paths that were illegal
on PC-DOS circa 1981 (like `aux`, `con`, `com1`) and that in a
bizarre fit of retrocomputing, remain illegal on some "modern"
computers, despite being "new technology".
Introduce some aspirational tests that suggest that we should be
able to cope with trees and indexes that contain paths that
would be illegal on the filesystem, so that we can at least diff
them. Further ensure that checkout will not write a repository
with forbidden paths.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We should be checking whether the object we're looking up is a commit,
and we should let the caller know whether the not-found return code
comes from a bad object type or just a missing signature.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When performing an in-memory rebase, keep a single index for the
duration, so that callers have the expected index lifecycle and
do not hold on to an index that is free'd out from under them.
|
|\ \ \ \
| | | | |
| | | | | |
rebase: introduce bare rebasing
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Allow callers of rebase to specify custom merge options. This may
allow custom conflict resolution, or failing fast when conflicts
are detected.
|
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Introduce the ability to rebase in-memory or in a bare repository.
When `rebase_options.inmemory` is specified, the resultant `git_rebase`
session will not be persisted to disk. Callers may still analyze
the rebase operations, resolve any conflicts against the in-memory
index and create the commits. Neither `HEAD` nor the working
directory will be updated during this process.
|
| | | | |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When we moved the logic to handle the first one, wrong loop logic was
kept in place which meant we still finished early. But we now notice it
because we're not reading past the last LF we find.
This was not noticed before as the last field in the tested commit was
multi-line which does not trigger the early break.
|
|\ \ \
| | | |
| | | | |
Introduce git_commit_extract_signature
|
| | |/
| |/|
| | |
| | |
| | |
| | | |
This returns the GPG signature for a commit and its contents without the
signature block, allowing for the verification of the commit's
signature.
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
We were searching only past the first header field, which meant we were
unable to find e.g. `tree` which is the first field.
While here, make sure to set an error message in case we cannot find the
field.
|
| |
| |
| |
| |
| |
| | |
Include dotfiles when copying template directory, which will handle
both a template directory itself that begins with a dotfile, and
any dotfiles inside the directory.
|
| |
| |
| |
| |
| | |
Ensure that we can handle template directories that begin with a
leading dot.
|
|/
|
|
|
| |
Ensure that `git_repository_init` honors the `init.templatedir`
configuration setting.
|
| |
|
| |
|
|\
| |
| | |
Line count overflow in git_blame_hunk and git_blame__entry
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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`.
|
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
|
| |
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>
|
| |
|
|\
| |
| | |
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.
|
| | |
|
| | |
|