| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This will tell us which numbers we were trying to compare, rather than
just telling us that they're different.
|
| | |
|
| |
|
|
|
|
| |
When confronted with a conflict in the index, `git_index_add_all`
should stage the working directory copy. If there is no file in the
working directory, the conflict should simply be removed.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Without this option, we would not be able to catch exec bit changes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
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.
|
| |
|
|
|
|
| |
Introduce `git_indexwriter`, to allow us to lock the index while
performing additional operations, then complete the write (or abort,
unlocking the index).
|
| | |
|
| | |
|
| |
|
|
|
| |
We need these directories to exist so cl_git_mkfile() can create the
files we ask it to.
|
| |
|
|
|
|
| |
Path validation may be influenced by `core.protectHFS` and
`core.protectNTFS` configuration settings, thus treebuilders
can take a repository to influence their configuration.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The entry_count field is the amount of index entries covered by a
particular cache entry, that is how many files are there (recursively)
under a particular directory.
The current code that attemps to do this is severely defincient and is
trying to count the amount of children, which always comes up to zero.
We don't even need to recount, since we have the information during the
cache creation. We can take that number and keep it, as we only ever
invalidate or replace.
|
| |
|
|
|
| |
If e.g. the root tree is invalidated, we still want to write out
its children, since those may still have valid cache entries.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
These test that we invalidate at the right levels and that we remove the
tree cache when clearing the index.
|
| |
|
|
| |
Signed-off-by: Sven Strickroth <email@cs-ware.de>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
If you enabled core.safecrlf on an LF-ending platform, we would
error even for files with all LFs. We should only be warning on
irreversible mappings, I think.
|
| |
|
|
|
| |
This is just laying some groundwork for internal index changes
that I'm working on.
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
More reflogness
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This fixes a typo I made for setting the sorted flag on the index
after a reload. That typo didn't actually cause any test failures
so I'm also adding a test that explicitly checks that the index is
correctly sorted after a reload when ignoring case and when not.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
This updates the git_pqueue to simply be a set of specialized
init/insert/pop functions on a git_vector.
To preserve the pqueue feature of having a fixed size heap, I
converted the "sorted" field in git_vectors to a more general
"flags" field so that pqueue could mix in it's own flag. This
had a bunch of ramifications because a number of places were
directly looking at the vector "sorted" field - I added a couple
new git_vector helpers (is_sorted, set_sorted) so the specific
representation of this information could be abstracted.
|
| | |
|
| | |
|
| |
|
|
| |
This was not converted when we converted the rest, so do it now.
|
| |
|
|
|
|
| |
This time actually checking return values in diff notify tests and
actually testing callbacks for the index all-all/update-all/etc
functions.
|
| | |
|
| | |
|
| |
|
