Symlinks on MacOS are written as UTF-8 NFD, but
readSymbolicLink().toString() converts to NFC with potentially fewer
bytes. May occur in particular if the link target has non-ASCII
characters for which the NFC and NFD encodings differ. This may lead
to an EOFException: Short read of block.
This causes all kinds of weird effects in EGit, ranging from failing
rebases (which report the exception to the user) to EGit decorations in
the navigator silently disappearing (and never coming back).
* Rename readContentAsNormalizedString() to readSymlinkTarget() as it's
called only for symlinks. Also make it protected.
* Fix by allowing the read to succeed even if less than the expected
number of bytes are returned by the entry's input stream.
* Override in FileTreeIterator to use fs.readSymlink() directly.
Includes a new MacOS-only test.
Change-Id: I264c5972d67b1cbb1ed690580f5706e671b9affd
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Spawn an ObjectReader from the ObjectInserter, so the flush can be
delayed at the end of the fetch.
Change-Id: I35fe8c8370c06c25262645202aec2b1318057c19
Signed-off-by: Zhen Chen <czhen@google.com>
The package-private method Repository::gitInternalSlash() is not
referenced from anywhere within the package.
Last uses were removed with
0f8743d4 "Remove deprecated Tree, TreeEntry, FileTreeEntry and friends"
6e9fdce9 "Kill GitIndex"
Signed-off-by: Rüdiger Herrmann <ruediger.herrmann@gmx.de>
Change-Id: I514bf684ad0da808f6523e9e46db9674a25e1fb5
CheckoutCommand was not returning updated and removed files in case of
an overall status of NONDELETED. That's status which occurs especially
on the Windows platform when Checkout wanted to delete files but the
filesystem doesn't allow this. The situation is more seldom on linux/mac
because open filehandles don't stop a deletion attempt and checkout
succeeds more often.
Change-Id: I4828008e58c09bd8f9edaf0f7eda0a79c629fb57
* stable-4.5:
Fix carrying over flags during a RevWalk
Change-Id: Ibf4573c5664271dfa7a6ecc3ede6eaad749f89d8
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
There was a bug when carrying over flags from a merge commit to its
non-first parents. The first parent of a merge commit was handled
differently and correct but the non-first parents are handled by a
recursive algorithm. Flags should be copied from the root merge commit
to parent-2, to grandparent-2, ... up to the limit of STACK_DEPTH==500
parents-levels. But the recursive algorithm was always copying only to
the direct parents of the merge commit and not the grand*-parents.
This seems to be no problem when commits are handled in a strict date
order because then copying only one level is no problem if children are
handled before parents. But when commits are not seperated anymore by
distinctive correct dates (e.g. because all commits have the same date)
then it may happen that a merge-parent is handled before the merge
commit and when dealing later with the merge commit one has to copy
flags down to more than one level
Bug: 501211
Change-Id: I2d79a7cf1e3bce21a490905ccd9d5e502d7b8421
Remove the JDK_HOME settings that were introduced to build against the
Java 1.7 libraries. Now that the minimum requirement is Java 1.8, this
is wrong and prevents use of Java 1.8 features.
Change-Id: I91a194c9449d7810ef02b038907dbbc708e600a5
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
These names are presented to users when they install JGit so they should
be consistent.
Bug: 496101
Change-Id: I88a1abd8c3717d9a2f958e3a39edb2dbce3a415b
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Change-Id: I26d69fb6d35c6fb120360ef143d1b1f565d4014c
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
There are already suppressions for the same warnings in other parts
of this class.
Change-Id: Ic3b45525c6c8200cba975d14c7650cedb4409a4d
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
UploadPackLogger is deprecated but will not be removed until
JGit version 5.0.
Suppress the unavoidable deprecation warnings on usages of the
interface that are kept for backwards compatibility.
Add a TODO so that we don't forget to remove it in 5.0.
Change-Id: Id248002b9bdf23db192427196d54c722a012106c
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
- raise minimum version for HttpClient packages to 4.3 since some of the
used classes aren't available in older versions
- recompute OSGi uses clauses
Change-Id: I8f0bff1433762561e02f7439db27a6a9e846c290
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* stable-4.5:
Turn off doclint also during Maven site generation
Prepare 4.5.1-SNAPSHOT builds
JGit v4.5.0.201609210915-r
Unconditionally close repository in unregisterAndCloseRepository
Change-Id: Ibfd11669cd74d2e62b014c18fd39b646b200c8c5
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Repository.close() method is used when reference counting and expiration
needs to be honored. The RepositoryCache.unregisterAndCloseRepository
method should close the repository unconditionally. This is also indicated
from its javadoc.
Change-Id: I19392d1eaa17f27ae44b55eea49dcff05a52f298
The class AtomicObjectOutputStream should be available to all lfs
related classes, not only to the server side. Move the class from
org.eclipse.jgit.lfs.server.fs to org.eclipse.jgit.lfs.internal to
achieve that.
Change-Id: I028e1c9ec7c21f316340b21d558b9a6b77e2060d
Adds a JGit built-in implementation of the "git lfs smudge" filter. This
filter should do the same as the one described in [1] besides that it
only supports the local case when the lfs objects are already present in
the media directory. Remote cases where download of LFS objects from an
LFS server is needed will be done in a later commit.
[1] https://github.com/github/git-lfs/blob/master/docs/man/git-lfs-smudge.1.ronn
Change-Id: I8ff661d4edd3667ef7f86f3b4fa33e568eb4c8f4
Adds a JGit built-in implementation of the "git lfs clean" filter. This
filter should do the same as the one described in [1]. But since this
filter is written in Java and can be called by JGit without forking new
processes it should be much faster
[1]
https://github.com/github/git-lfs/blob/master/docs/man/git-lfs-clean.1.ronn
Change-Id: If60e387e97870245b4bd765eda6717eb84cffb1d
If the configuration parameter filter.<filterDriverName>.useJGitBuiltin
is set to true then for all corresponding filters JGit will try to
execute the built-in filter instead of the filter-command which is
defined in git configuration. It will fallback to the non-built-in
filters if no built-in filters are registered or if constructing them
leads to exceptions. If set to false JGit will not try to execute
built-in filters for the specified filter driver.
Example: The configuration contains the following lines
[filter "lfs"]
clean = git-lfs clean -- %f
smudge = git-lfs smudge -- %f
useJGitBuiltin = true
Addtionally the .gitattributes file in the root of the working tree
contains:
*.bin filter=lfs
In this case when new content is added similar to "git add 1.bin" then
the following will happen:
- jgit will check whether a built-in command factory was registered
for the command "jgit://builtin/lfs/clean". If that is true the
factory is used to create a built-in filter command and that
command is used to filter the content
- Otherwise jgit will call the external program "git lfs clean ..."
to do the filtering
Change-Id: Idadb1db06b1e89e7031d7ed6319904973c367d38
JGit supports smudge filters defined in repository configuration. The
filters are implemented as external programs filtering content by
accepting the original content (as seen in git's object database) on
stdin and which emit the filtered content on stdout. This content is
then written to the file in the working tree. To run such a filter JGit
has to start an external process and pump data into/from this process.
This commit adds support for built-in smudge filters which are
implemented in Java and which are executed by jgit's main thread. When a
filter is defined in the configuration as
"jgit://builtin/<filterDriverName>/smudge" then JGit will lookup in a
static map whether a builtin filter is registered under this name. If
found such a filter is called to do the filtering.
The functionality in this commit requires that a program using JGit
explicitly calls the JGit API to register built-in implementations for
specific smudge filters. In follow-up commits configuration parameters
will be added which trigger such registrations.
Change-Id: Ia743aa0dbed795e71e5792f35ae55660e0eb3c24
JGit supports clean filters defined in repository configuration. The
filters are implemented as external programs filtering content by
accepting the original content (as seen in the working tree) on stdin
and which emit the filtered content on stdout. To run such a filter JGit
has to start an external process and pump data into/from this process.
This commit adds support for clean filters which are implemented
in Java and which are executed by jgit's main thread. When a filter is
defined in the configuration as
"jgit://builtin/<filterDriverName>/clean" then JGit will lookup in a
static map whether a filter is registered under this name. If found
such a filter is called to do the filtering.
The functionality in this commit requires that a program using JGit
explicitly calls the JGit API to register built-in implementations for
specific clean filters. In follow-up commits configuration parameters
will be added which trigger such registrations. Other commits will add
implementations for lfs filters.
Change-Id: I0344d3c54801c9a46e5a606c5df17e5f2e17b2be
This is like PackStatistics, but for PackParser.
Change-Id: I854215c0956fd0b36843d631780be303e021b8be
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
BranchConfig treated this config property as a boolean, but git also
allows the values "preserve" and "interactive". Config property
pull.rebase also allows the same values.
Replace private enum PullCommand.PullRebaseMode by new public enum
BranchConfig.BranchRebaseMode and adapt all uses. Add a new setter to
PullCommand.
Note: PullCommand will treat "interactive" like "true", i.e., as a
non-interactive rebase. Not sure how "interactive" should be handled.
At least it won't balk on it.
Bug: 499482
Change-Id: I7309360f5662b2c2efa1bd8ea6f112c63cf064af
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Change-Id: I6691b454404dd4db3c690ecfc7515de765bc2ef7
Signed-off-by: Martin Goellnitz <m.goellnitz@outlook.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
- enhance FS.readPipe to throw an exception if the external command
fails to enable the caller to handle the command failure
- reduce log level to warning if system git config does not exist
- improve log message
Bug: 476639
Change-Id: I94ae3caec22150dde81f1ea8e1e665df55290d42
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Without the bridge JGit tests don't show log output in Eclipse console.
Change-Id: I7acce1f1787960b5ca98377cb5c7f599a8a220b5
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Since 4.0 JGit does no longer support Java versions older than Java 7 so
there is no need anymore to mention Java 7 in the class name.
Change-Id: Ic46c9d89a7e919ae4a69487fa06de0478d2b21f0
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Guide implementors which exception to throw in case of errors.
Change-Id: I74fb76cdf6b7cdef513f3fe8c144572e869cc533
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Change-Id: I438456b76aefd361384729686271288186d3be3b
Signed-off-by: Ned Twigg <ned.twigg@diffplug.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Instead of returning null, LfsProtocolServlet#getLargeFileRepository
should throw LfsUnavailable.
If null is returned, throw a generic LfsException.
Handle LfsException as an internal server error and return HTTP 500.
Change-Id: I33e2a19fcc0fde8aaf0f703860c8fa8ce2de2db5
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Thomas Wolf
Christian Halstrick
Matthias Sohn
Zhen Chen
Rüdiger Herrmann
Shawn Pearce
David Pursehouse
Saša Živkov
Masaya Suzuki
Andrey Loskutov
Martin Goellnitz
Ned Twigg