Thomas Wolf [Sun, 12 Aug 2018 17:30:36 +0000 (19:30 +0200)]
Fix core.autocrlf for non-normalized index
With text=auto or core.autocrlf=true, git does not normalize upon
check-in if the file in the index contains already CR/LFs. The
documentation says: "When text is set to "auto", the path is
marked for automatic end-of-line conversion. If Git decides that
the content is text, its line endings are converted to LF on
checkin. When the file has been committed with CRLF, no conversion
is done."[1]
Implement the last bit as in canonical git: check the blob in the
index for CR/LFs. For very large files, we check only the first 8000
bytes, like RawText.isBinary() and AutoLFInputStream do.
In Auto(CR)LFInputStream, ensure that the buffer is filled as much as
possible for the isBinary() check.
Regarding these content checks, there are a number of inconsistencies:
* Canonical git considers files containing lone CRs as binary.
* RawText checks the first 8000 bytes.
* Auto(CR)LFInputStream checks the first 8096 (not 8192!) bytes.
None of these are changed with this commit. It appears that canonical
git will check the whole blob, not just the first 8k bytes. Also
note: the check for CR/LF text won't work with LFS (neither in JGit
nor in git) since the blob data is not run through the smudge filter.
C.f. [2].
Two tests in AddCommandTest actually tested that normalization was
done even if the file was already committed with CR/LF.These tests
had to be adapted. I find the git documentation unclear about the
case where core.autocrlf=input, but from [3] it looks as if this
non-normalization also applies in this case.
Add new tests in CommitCommandTest testing this for the case where
the index entry is for a merge conflict. In this case, canonical git
uses the "ours" version.[4] Do the same.
Thomas Wolf [Tue, 29 Jan 2019 21:20:07 +0000 (22:20 +0100)]
Atomic file creation: hard-linking may not be allowed
Android for instance forbids hard linking via a SELinux
policy. If we can't hard link, the NFS work-around for
atomic file creation cannot work at all. In this case,
fall back to not using the hard-linking mechanism.
Android throws an AccessDeniedException, so we catch that.
The javadoc on Files.createLink() indicates that another
possibility might be a SecurityException, so catch that,
too.
Bug: 543956
Change-Id: I551b7a45f7b2fbbd8cf94f0b7233dbd8a200520e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Matthias Sohn [Sun, 27 Jan 2019 01:22:34 +0000 (02:22 +0100)]
Fix GC.deleteEmptyRefsFolders
This method tried to iterate spurious files which may exist in the
.git/refs folder, e.g. on Mac a .DS_Store may have been created there by
inspecting the folder using the finder application. This led to a
NotDirectoryException when deleteEmptyRefsFolders tried to create an
iterator for such a file entry. Skip files contained in the refs folder
to ensure the method only tries to iterate contained folders but not
files.
Change-Id: I5f31e733072a35db1e93908a9c69a8891ae5c206 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Thomas Wolf [Mon, 10 Dec 2018 23:47:13 +0000 (00:47 +0100)]
Enable cloning only specific tags
Single-branch-clone should be able to clone a single tag. Enhance
CloneCommand to accept also full refs of tags in setBranchesToClone().
Make sure we also include fetch ref specs for the fetch command for
tags. This mimics the behavior of native git's single-branch clone:
git clone --branch <tag> --single-branch <URI>
Bug: 542611
Change-Id: I285cf043751d9b0ba71258ee8214c0e5d1191428 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Matthias Sohn [Fri, 25 Jan 2019 23:34:08 +0000 (00:34 +0100)]
Add 4.11-staging target platform and update Orbit to I20190123233226
Update
- org.apache.httpcomponents.httpcore to 4.4.10.v20190123-2214
- org.apache.httpcomponents.httpclient.source to 4.5.6.v20190123-2215
- org.bouncycastle.bcpg to 1.60.0.v20181210-2057
- org.bouncycastle.pkix to 1.60.0.v20181210-2057
- org.bouncycastle.prov to 1.60.0.v20181210-2057
Change-Id: I132b6686aa29b2a76cc529f7cae34115604c754d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Thomas Wolf [Thu, 6 Dec 2018 14:49:25 +0000 (15:49 +0100)]
RenameBranchCommand: more consistent handling of short ref names
Several problems:
* The command didn't specify whether it expected short or full names.
* For the new name, it expected a short name, but then got confused
if tags or both local and remote branches with the same name existed.
* For the old name, it accepted either a short or a full name, but
again got confused if a short name was given and a tag with the
same name existed.
With such an interface, one cannot use Repository.findRef() to
reliably find the branch to rename. Use exactRef() for the new
name as by the time the Ref is needed its full name is known.
For determining the old Ref from the name, do the resolution
explicitly: first try exactRef (assuming the old name is a full
name); if that doesn't find anything, try "refs/heads/<old>" and
"refs/remotes/<old>" explicitly. Throw an exception if the name
is ambiguous, or if exactRef returned something that is not a
branch (refs/tags/... or also refs/notes/...).
Document in the javadoc what kind of names are valid, and add tests.
A user can still shoot himself in the foot if he chooses exceptionally
stupid branch names. For instance, it is still possible to rename a
branch to "refs/heads/foo" (full name "refs/heads/refs/heads/foo"),
but it cannot be renamed further using the new short name if a branch
with the full name "refs/heads/foo" exists. Similar edge cases exist
for other dumb branch names, like a branch with the short name
"refs/tags/foo". Renaming using the full name is always possible.
Bug: 542446
Change-Id: I34ac91c80c0a00c79a384d16ce1e727c550d54e9 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Provide a mechanism for a subclass to provide its own set
of default identities from anywhere as an Iterable<KeyPair>.
The default implementation is functionally unchanged and uses
the known default identity files in the ~/.ssh directory. A subclass
can override the getDefaultKeys() function and return whatever keys
are appropriate.
Bug: 543152
Change-Id: I500d63146bc67e20e051f617790eb87c7cb500b6 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
David Pursehouse [Mon, 21 Jan 2019 06:35:38 +0000 (15:35 +0900)]
SmartClientSmartServerTest: Open Repository in try-with-resource
Since 52923e9 ("LocalDiskRepositoryTestCase#createRepository: Default
auto-close to false", Jan 20, 2019) the createBareRepository method
creates repositories that do not get automatically closed in #tearDown.
Convert invocations of createBareRepository to use try-with-resource.
Change-Id: I320030c5d4438713971bee33316bff408bac47fc Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
David Pursehouse [Mon, 21 Jan 2019 04:28:22 +0000 (13:28 +0900)]
UnionInputStreamTest: Open UnionInputStream in try-with-resource
The tests were written for Java 7 which did not have AutoCloseable
and the try-with-resource concept. When the project was updated to
build with Java 8, the warnings were suppressed.
Remove the suppressions and convert to use try-with-resource.
Change-Id: Ic805bd571c4a2e4376ce5e7c34ca7ac86cbf5104 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
David Pursehouse [Sun, 20 Jan 2019 11:25:53 +0000 (20:25 +0900)]
RawParseUtils: Avoid import of java.nio.charset.StandardCharsets
The import is only needed because of a reference to it in the Javadoc,
and can be avoided by explicitly specifying the package instead, which
is how it's referenced in other cases (Constants, FileHeader).
Change-Id: I0c6254a9adf1f52fb8f2c04a858b11696ad264f5 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
David Pursehouse [Sun, 20 Jan 2019 10:58:10 +0000 (19:58 +0900)]
LocalDiskRepositoryTestCase#createRepository: Default auto-close to false
Since 8ed59c5 ("Make TestRepository AutoCloseable", Jan 11, 2019) the
TestRepository class is auto-closeable, but instantiations of it were
not converted to use try-with-resource.
Converting to try-with-resource results, in several cases, in the
repository being closed twice because LocalDiskRepositoryTestCase has
logic to close created repositories in the tearDown method. This results
in several tests emitting a warning to the console:
close() called when useCnt is already zero
Change the default behavior of the createRepository method to not use
the auto-close logic in LocalDiskRepositoryTestCase, so that thy will
instead be closed (only once) using the AutoCloseable implementation.
Deprecate the method that has the autoClose parameter.
Change-Id: I63d62c9913f9b61271667861dae144e551d358c1 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
projects / jgit.git / log