| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
index: canonicalize directory case when adding
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On case insensitive systems, when given a user-provided path in the
higher-level index addition functions (eg `git_index_add_bypath` /
`git_index_add_frombuffer`), examine the index to try to match the
given path to an existing directory.
Various mechanisms can cause the on-disk representation of a folder
to not match the representation in HEAD or the index - for example,
a case changing rename of some file `a/file.txt` to `A/file.txt`
will update the paths in the index, but not rename the folder on
disk.
If a user subsequently adds `a/other.txt`, then this should be stored
in the index as `A/other.txt`.
|
| |\ \
| |/
|/| |
New feature: add the ablility to iterate through a directory in index
|
| | |
| |
| |
| | |
Find the first index entry matching a prefix.
|
| |\ \
| | |
| | | |
filebuf: follow symlinks when creating a lock file
|
| | |/
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| |/
|/| |
Use a hashmap for path-based lookups in the index
|
| | |
| |
| |
| |
| | |
We were missing tests for switching the case-sensitivity of an index
in-memory and then looking up entries in it.
|
| |\ \
| | |
| | | |
Provide path matching in the iterators (for faster diffs)
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some nicer refactoring for index iteration walks.
The index iterator doesn't binary search through the pathlist space,
since it lacks directory entries, and would have to binary search
each index entry and all its parents (eg, when presented with an index
entry of `foo/bar/file.c`, you would have to look in the pathlist for
`foo/bar/file.c`, `foo/bar` and `foo`). Since the index entries and the
pathlist are both nicely sorted, we walk the index entries in lockstep
with the pathlist like we do for other iteration/diff/merge walks.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When using literal pathspecs in diff with `GIT_DIFF_DISABLE_PATHSPEC_MATCH`
turn on the faster iterator pathlist handling.
Updates iterator pathspecs to include directory prefixes (eg, `foo/`)
for compatibility with `GIT_DIFF_DISABLE_PATHSPEC_MATCH`.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Document that `GIT_DIFF_PATHSPEC_DISABLE` is not necessarily about
explicit path matching, but also includes matching of directory
names. Enforce this in a test.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When given a pathlist, don't assume that directories sort before
files. Walk through any list of entries sorting before us to make
sure that we've exhausted all entries that *aren't* directories.
Eg, if we're searching for 'foo/bar', and we have a 'foo.c', keep
advancing the pathlist to keep looking for an entry prefixed with
'foo/'.
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ /
|/| | |
win32: ensure hidden files can be staged
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
When parsing user-provided regex patterns for functions, we must not
fail to provide a diff just because a pattern is not well
formed. Ignore it instead.
|
| |\ \ \
| | | |
| | | | |
Locking and transactional/atomic updates for config
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This makes the API for commiting or discarding changes the same as for
references.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
When a configuration file is locked, any updates made to it will be done
to the in-memory copy of the file. This allows for multiple updates to
happen while we hold the lock, preventing races during complex
config-file manipulation.
|
| |/ /
| |
| |
| |
| |
| | |
While we download the remote's remote-tracking branches, we don't
download the tag. This points to the tag auto-follow rules interfering
with the refspec.
|
| | |
| |
| |
| |
| | |
When an error state is an OOM, make sure that we treat is specially
and do not try to free it.
|
| | | |
|
| |/ |
|
| |\
| |
| | |
filebuf: remove lockfile upon rename errors
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we have an error renaming the lockfile, we need to make sure
that we remove it upon cleanup. For this, we need to keep track of
whether we opened the file and whether the rename succeeded.
If we did create the lockfile but the rename did not succeed, we
remove the lockfile. This won't protect against all errors, but
the most common ones (target file is open) does get handled.
|
| | |
| |
| |
| |
| | |
When we fail to rename, we currently leave the lockfile laying
around. This shows that behaviour.
|
| | |
| |
| |
| |
| |
| | |
When we pass the path of a repository to `_bypath()`, we should behave
like git and stage it as a `_COMMIT` regardless of whether it is
registered a a submodule.
|
| | | |
|
| |\ \
| | |
| | | |
iterator: skip over errors in diriter init
|
| | |/
| |
| |
| |
| | |
We don't want the iterator to make us stop whenever we hit an unreadable
dir. We should instead move over to the next item.
|
| |\ \
| | |
| | | |
Normalize submodule urls before looking at them
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Allow adding a submodule through git_index_add_bypath
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Similarly to how git itself does it, allow the index update operation to
stage a change in a submodule's HEAD.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This also affects `git_index_add_bypath()` by providing a better error
message and a specific error code when a directory is passed.
|
| |\ \ \ \
| |_|_|/
|/| | | |
refdb: delete a ref's reflog upon deletion
|
| | |/ /
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \
| |_|/
|/| | |
List a submodule only once when the path matches a submodule in the index
|
| | | |
| | |
| | |
| | |
| | |
| | | |
When we rename a submodule, we should be merging two sets of information
based on whether their path is the same. We currently only deduplicate
on equal name, which causes us to double-report.
|
