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>
After 1cd65991, we were passing a pointer to an `unsigned long` to
a function that now expected a pointer to a `size_t`. These types
differ on 64-bit Windows, which means that we trash the stack.
Use `size_t`s in the packbuilder to avoid this.
Somehow I ended up with the following in my ~/.gitconfig:
[branch "master"]
remote = origin
merge = master
rebase = true
I assume something went crazy while I was running the git.git tests
some time ago, and that I never noticed until now.
This is not a good configuration, but it shouldn't cause problems. But
it does. Specifically, if you have this in your config, and you
perform the following set of actions:
create a remote
fetch from that remote
create a branch off of the remote master branch called "master"
delete the branch
delete the remote
The remote delete fails with the message "Could not find key
'branch.master.rebase' to delete". This is because it's iterating over
the config entries (including the ones in the global config) and
believes that there is a master branch which must therefore have these
config keys.
https://github.com/libgit2/libgit2/issues/3856
The callback mechanism makes it awkward to write data from an IO
source; move to `_fromstream()` which lets the caller remain in control,
in the same vein as we prefer iterators over foreach callbacks.
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.
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.
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.
We create a lockfile to update files under GIT_DIR. Sometimes these
files are actually located elsewhere and a symlink takes their place. In
that case we should lock and update the file at its final location
rather than overwrite the symlink.
This lock/unlock pair allows for the cller to lock a configuration file
to avoid concurrent operations.
It also allows for a transactional approach to updating a configuration
file. If multiple updates must be made atomically, they can be done
while the config is locked.
Removing a reflog upon ref deletion is something which only some
backends might wish to do. Backends which are database-backed may wish
to archive a reflog, log-based ones may not need to do anything.
The function was removed, but its declaration and changelog entry about
its removal were forgotten.
The comment in the test doesn't make any sense as the function doesn't
exist anymore, so get rid of it as well.
Allow custom filters with wildcard attributes, so that clients
can support some random `filter=foo` in a .gitattributes and look
up the corresponding smudge/clean commands in the configuration file.
