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.
remote: check the relevance of the refspec when updating FETCH_HEAD
Before trying to rtransform using the given refspec to figure out what
the name of the upstream branch is on the remote, we must make sure that
the target of the refspec applies to the current branch's upstream.
John Fultz [Mon, 3 Nov 2014 01:16:49 +0000 (19:16 -0600)]
Clean up issues include.path issues found during code review.
* 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.
The create function with default refspec is the same as the one with a
custom refspec, but it has the default refspec, so we can create the one
on top of the other.
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.
remote: add a failing test for checking the current branch's upstream
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.
netops: return GIT_ECERTIFICATE when it fails the basic tests
When we first ask OpenSSL to verify the certfiicate itself (rather
than the HTTPS specifics), we should also return
GIT_ECERTIFICATE. Otherwise, the caller would consider this as a failed
operation rather than a failed validation and not call the user's own
validation.
John Fultz [Sat, 1 Nov 2014 16:21:45 +0000 (11:21 -0500)]
Make config reading continue after hitting a missing include file.
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.
Talk about sharing objects and error messages; but the most important
part is about what to do with the cryptographic libraries, which sadly
have to become to responsibility of the application.
Threads are here to stay; and for a while now, users have had to call
the initialization function which sets up threads and crypto regardless
of whether the library was built threadsafe or not.
Edward Thomson [Fri, 18 Jul 2014 18:50:06 +0000 (14:50 -0400)]
git_rebase_commit: drop already-picked commits
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.
Edward Thomson [Tue, 15 Jul 2014 14:23:10 +0000 (10:23 -0400)]
Introduce git_rebase_next
`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.
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.
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.
All versions of SSL are considered deprecated now, so let's ask OpenSSl
to only use TLSv1. We still ask it to load those ciphers for
compatibility with servers which want to use an older hello but will use
TLS for encryption.
For good measure we also disable compression, which can be exploitable,
if the OpenSSL version supports it.
Edward Thomson [Tue, 14 Oct 2014 20:31:55 +0000 (16:31 -0400)]
Remote paths: canonicalize UNC paths on Win32
Git for Windows will handle UNC paths only when in forward-slash
format, eg "//server/path". When given a UNC path as a remote,
rewrite standard format ("\\server\path") into this ridiculous
format.
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.
projects / libgit2.git / log