| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
git hardocodes these as objects which exist regardless of whether they
are in the odb and uses them in the shell interface as a way of
expressing the lack of a blob or tree for one side of e.g. a diff.
In the library we use each language's natural way of declaring a lack of
value which makes a workaround like this unnecessary. Since git uses it,
it does however mean each shell application would need to perform this
check themselves.
This makes it common work across a range of applications and an issue
with compatibility with git, which fits right into what the library aims
to provide.
Thus we introduce the hard-coded empty blob and tree in the odb
frontend. These hard-coded objects are checked for before going to the
backends, but after the cache check, which means the second time they're
used, they will be treated as normal cached objects instead of creating
new ones.
|
|
|
|
|
|
|
|
|
|
|
|
| |
We cannot know from looking at .gitmodules whether a directory is a
submodule or not. We need the index or tree we are comparing against to
tell us. Otherwise we have to assume the entry in .gitmodules is stale
or otherwise invalid.
Thus we pass the index of the repository into the workdir iterator, even
if we do not want to compare against it. This follows what git does,
which even for `git diff <tree>`, it will consider staged submodules as
such.
|
|
|
|
|
|
|
|
|
| |
We consider an entry in .gitmodules to mean that we have a submodule at
a particular path, even if HEAD^{tree} and the index do not contain any
reference to it.
We should ignore that submodule entry and simply consider that path to
be a regular directory.
|
| |
|
| |
|
|\
| |
| | |
ignore: don't leak rules into higher directores
|
| |
| |
| |
| |
| | |
When we mention "src" in src/.gitignore, we wrongly consider src/ itself
to be ignored.
|
|\ \
| |/
|/| |
remote: check for the validity of the refspec when updating FETCH_HEAD
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we update FETCH_HEAD we check whether the remote is the current
branch's upstream remote. The code does not check whether the current
refspec is relevant for this reference but always tries to perform the
reverse transformation, which causes it to error out if the refspec
doesn't match the reference.
Thanks to Pierre-Olivier Latour for the reproduction recipe.
|
|\ \
| | |
| | | |
ignore: consider files with a CR in their names
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We currently consider CR to start the end of the line, but that means
that we miss cases with CR CR LF which can be used with git to match
files whose names have CR at the end of their names.
The fix from the patch comes from Russell's comment in the issue.
This fixes #2536.
|
| | | |
|
|\ \ \
| |/ /
|/| | |
Make config reading continue after hitting a missing include file.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Error-handling is cleaned up to only let a file-not-found error
through, not other sorts of errors. And when a file-not-found
error happens, we clean up the error.
* Test now checks that file-not-found introduces no error. And
other minor cleanups.
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For example, if you have
[include]
path = foo
and foo didn't exist, git_config_open_ondisk() would just give up
on the rest of the file. Now it ignores the unresolved include
without error and continues reading the rest of the file.
|
|/
|
|
|
|
|
|
|
|
|
| |
An anonymous remote wouldn't create remote-tracking branches, so testing
we don't create them for TAGS_ALL is nonsensical. Furthermore, the name
of the supposed remote-tracking branch was also not one which would have
been created had it had a name.
Give the remote a name and test that we only create the tags when we
pass TAGS_ALL and that we do create the remote-branch branch when given
TAGS_AUTO.
|
| |
|
|
|
|
|
| |
Rename git_merge_head to git_annotated_commit, as it becomes used
in more operations than just merge.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Already cherry-picked commits should not be re-included. If all changes
included in a commit exist in the upstream, then we should error with
GIT_EAPPLIED.
|
|
|
|
| |
Commit the current patch of a rebase process.
|
| |
|
|
|
|
|
|
| |
`git_rebase_next` will apply the next patch (or cherry-pick)
operation, leaving the results checked out in the index / working
directory so that consumers can resolve any conflicts, as appropriate.
|
|
|
|
|
| |
Abort an in-progress rebase and move the working directory and
repository back to the ORIG_HEAD state.
|
|
|
|
|
|
| |
Introduce `git_rebase` to set up a rebase session that can
then be continued. Immediately, only merge-type rebase is
supported.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
config: remove the refresh function and backend field
|
| |
| |
| |
| |
| |
| | |
We have been refreshing on read and write for a while now, so
git_config_refresh() is at best a no-op, and might just end up wasting
cycles.
|
|\ \
| | |
| | | |
remote: accept a repo and name for renaming
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remote objects are not meant to be changed from under the user. We did
this in rename, but only the name and left the refspecs, such that a
save would save the wrong refspecs (and a fetch and anything else would
use the wrong refspecs).
Instead, let's simply take a name and not change any loaded remote from
under the user.
|
|\ \
| | |
| | | |
clar: use a custom temp directory name
|
| |/ |
|
|/
|
|
|
|
|
| |
This function does not in fact tell us anything, as almost anything with
a colon in it is a valid rsync-style SSH path; it can not tell us that
we do not support ftp or afp or similar as those are still valid SSH
paths and we do support that.
|
|\
| |
| | |
Refresh git configuration before looking for the tracking branch redux.
|
| | |
|
| | |
|