| 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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Since commit 394951ad4 (tests: allow for simple data-driven
tests, 2019-06-07), we have the ability to run a given test suite
with multiple variants. Use this new feature to deduplicate the
test suites for merge::{trees,workdir}::analysis into a single
test suite.
|
| |
|
|
|
|
| |
- whitespace -> tabs
- comment style
- improve repo naming in merge/trees/analysis tests.
|
| |
|
|
|
| |
- move duplication between merge/trees/ and merge/workdir/ into merge/analysis{.c,.h}
- remove merge-resolve.git resource, open the existing merge-resolve as a bare repo instead.
|
| | |
|
| |
|
|
| |
Use the new object_type enumeration names within the codebase.
|
| |\
| |
| | |
Allow merge analysis against any reference
|
| | |
| |
| |
| |
| |
| |
| | |
This moves the current merge analysis code into a more generic version
that can work against any reference.
Also change the tests to check returned analysis values exactly.
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| | |
Adds a test case for the issue #4203, when diverging indexes
on memory and disk cause git merge to abort with GIT_ECONFLICT
|
| |\ \
| | |
| | | |
Assorted Coverity fixes
|
| | | |
| | |
| | | |
Reported by Coverity, CID 1393678-1393697.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the commits being merged have multiple merge bases, reverse the
order when creating the virtual merge base. This is for compatibility
with git's merge-recursive algorithm, and ensures that we build
identical trees.
Git does this to try to use older merge bases first. Per 8918b0c:
> It seems to be the only sane way to do it: when a two-head merge is
> done, and the merge-base and one of the two branches agree, the
> merge assumes that the other branch has something new.
>
> If we start creating virtual commits from newer merge-bases, and go
> back to older merge-bases, and then merge with newer commits again,
> chances are that a patch is lost, _because_ the merge-base and the
> head agree on it. Unlikely, yes, but it happened to me.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Git uses longer conflict markers in the recursive merge base - two more
than the default (thus, 9 character long conflict markers). This allows
users to tell the difference between the recursive merge conflicts and
conflicts between the ours and theirs branches.
This was introduced in git d694a17986a28bbc19e2a6c32404ca24572e400f.
Update our tests to expect this as well.
|
| |/
|
|
| |
modify/deltete conflict
|
| | |
|
| |
|
|
|
| |
Update unit test to use newfangled `st_ctime_nsec`, which provides
indirection to the platform-correct name.
|
| |
|
|
|
| |
Windows defines `timeval` with `long`, which we cannot
sanely cope with. Instead, use a custom timeval struct.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
As we attempt to replicate a situation in which an older checkout has
put a file on disk with different filtering settings from us, set the
timestamp on the entry and file to a second before we're performing the
operation so the entry in the index counts as old.
This way we can test that we're not looking at the on-disk file when the
index has the entry and we detect it as clean.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
This function is meant to simulate what git does in the reset command,
so we should include the reflog message in that.
|
| |
|
|
|
|
|
|
|
|
| |
The signature for the reflog is not something which changes
dynamically. Almost all uses will be NULL, since we want for the
repository's default identity to be used, making it noise.
In order to allow for changing the identity, we instead provide
git_repository_set_ident() and git_repository_ident() which allow a user
to override the choice of signature.
|
| |
|
|
|
|
|
|
|
|
| |
Always lock the index when we begin the merge, before we write
any of the metdata files. This prevents a race where another
client may run a commit after we have written the MERGE_HEAD but
before we have updated the index, which will produce a merge
commit that is treesame to one parent. The merge will finish and
update the index and the resultant commit would not be a merge at
all.
|
| |
|
|
|
|
| |
Correct the merge failed cleanup test. Merge data should not be
cleaned up on conflicts, only on actual failure. And ORIG_HEAD
should not be removed at all.
|
| | |
|
| |
|
|
|
| |
Rename git_merge_head to git_annotated_commit, as it becomes used
in more operations than just merge.
|
| |
|
|
| |
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
| |
|
|
|
|
|
|
| |
git_checkout_index can now check out other git_index's (that are not
necessarily the repository index). This allows checkout_index to use
the repository's index for stat cache information instead of the index
data being checked out. git_merge and friends now check out their
indexes directly instead of trying to blend it into the running index.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
git_merge_analysis will now return GIT_MERGE_CONFIG_NO_FASTFORWARD
when merge.ff=false and GIT_MERGE_CONFIG_FASTFORWARD_ONLY when
merge.ff=true
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
