Matthias Sohn [Wed, 22 Apr 2015 10:53:35 +0000 (12:53 +0200)]
Restore AwtCredentialsProvider to enable debugging pgm in Eclipse
In 6c1f7393882baf8464859136a70199ea96fcae0f the AWT based credentials
provider was dropped because we don't support Java 5 any longer so we
can always use the ConsoleCredentialsProvider which requires Java 6.
This broke debugging org.eclipse.jgit.pgm since Eclipse doesn't support
using a system console authenticator [1].
[1] see https://bugs.eclipse.org/bugs/show_bug.cgi?id=148831
David Pletcher [Thu, 16 Apr 2015 19:47:15 +0000 (12:47 -0700)]
Expose public getDepth method
The clone or fetch depth is a valuable bit of information
for access logging. Create a public getter to faciliate access.
A precondition check prevents unintentional misuse when the
data isn't valid yet.
Change-Id: I4603d5fd3bd4a767e3e2419b0f2da3664cfbd7f8 Signed-off-by: David Pletcher <dpletcher@google.com>
When a user tried to use a service not enabled in the remote server
a misleading error message was given:
fatal: remote error: Git access forbidden
This patch modifies the error message to make the cause clearer
to the user. Now, when the user tries to use a not enabled service,
the message error clearly states it:
Most callers/users of TemporaryBuffer are sizing the in-memory
portion large enough that most outputs fit into RAM. With this
assumption they don't pay close attention to the size of IOs
being written, as it "should" just be a copy from one byte array
to another.
Overflow sets up a local file handle, which is costly to write to
for small IO units. Wrap the local file in a BufferedOutputStream
to combine small writes together. Larger writes can still bypass the
buffer as BOS automatically avoids copying for larger writes.
When reading back from an overflowed TemporaryBuffer the InputStream
must be closed to close the FileInputStream that is reading from
the backing file.
Formatting merge conflicts one byte at a time is going to be very
slow when the final OutputStream is a FileOutputStream and the JVM
is making system calls for each byte output.
When outputting a range of bytes from a byte[] the bol (beginning
of line) value only depends on the value of the last byte written.
Other bytes in the array can be passed directly to the lower stream
for more efficient output.
Do not add a newline at the end if neither merged side had one
Bug: 390833
Change-Id: I29f7b79b241929877c93ac485c677487a91bb77b Signed-off-by: André de Oliveira <andre.oliveira@liferay.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Laurent Delaigue [Fri, 21 Nov 2014 10:28:19 +0000 (11:28 +0100)]
Make RepositoryState.REBASING_MERGE reachable again.
If a non interactive rebase is launched, stopping after a conflict
should set the repository state to RepositoryState.REBASING_MERGE
instead of RepositoryState.REBASING_INTERACTIVE.
Bug: 452623
Change-Id: Ie885aab6d71dabd158a718af0d14fff643c9b850 Also-by: Arthur Daussy <arthur.daussy@obeo.fr> Signed-off-by: Laurent Delaigue <laurent.delaigue@obeo.fr> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Fix RecursiveMerger in case of multiple, independent base commits
When RecursiveMerger found that there are multiple base-commits for the
commits to be merged it tries to temporarily merge the base commits. But
if these base commits have no common predecessor there was a bug in JGit
leading to a NPE. This commit fixes this by enforcing that an empty tree
is used as base when merging two unrelated base commits.
This logic was already there when merging two commits which have no
common predecessor (ThreeWayMerger.mergeBase()). But the code which was
computing a new temporary base commit in case of criss-cross merges
didn't take care to pick an empty tree when no common predecessor can be
found.
Dave Borowitz [Wed, 18 Mar 2015 17:46:41 +0000 (10:46 -0700)]
TestRepository: Add a cherryPick method
CherryPickCommand only works on a non-bare repository, as it must
modify the working tree and index in case of a merge conflict. In
tests, being able to recover from a merge conflict is less important,
as the caller should be able to control the full contents of files in
advance of the cherry-pick.
Matthias Sohn [Mon, 9 Mar 2015 22:57:48 +0000 (15:57 -0700)]
Include slf4j and log4j in jgit command line
This enables the command line to log. Include log4j configuration to log
warnings and errors to stderr.
Exclude the dependencies which log4j 1.2.15 should have marked optional.
See
http://unitstep.net/blog/2009/05/18/resolving-log4j-1215-dependency-problems-in-maven-using-exclusions/
for details
Change-Id: Ie730db4007fb7614fd7d130cd0858b1ac550066a Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Until git v1.7.10.2~29^2~1 (builtin/merge.c: reduce parents early,
2012-04-17), C git merge would make merge commits with duplicate parents
when asked to with a series of commands like the following:
Nowadays "git merge" removes redundant parents more aggressively
(whenever one parent is an ancestor of another and not just when
duplicates exist) but merges with duplicate parents are still permitted
and can be created with git fast-import or git commit-tree and history
viewers need to be able to cope with them.
CommitBuilder is an interface analagous to commit-tree, so it should
allow duplicate parents. (That said, an option to automatically remove
redundant parents would be useful.)
Reported-by: Dave Borowitz <dborowitz@google.com>
Change-Id: Ia682238397eb1de8541802210fa875fdd50f62f0 Signed-off-by: Jonathan Nieder <jrn@google.com>
Dave Borowitz [Wed, 18 Mar 2015 19:51:40 +0000 (12:51 -0700)]
TemporaryBuffer: Clear block pointer list instead of reallocating
The block pointer list may have been relatively large, so no need to
make more garbage. Instead, just clear the list and null out all the
elements.
Another possible motivation: a caller may have provided an inaccurate
estimated size, so the list might have been resized several times. If
the list is reused later for a similarly underestimated workload, this
fix will prevent additional resizing on subsequent usages.
Dave Borowitz [Wed, 18 Mar 2015 18:04:26 +0000 (11:04 -0700)]
TemporaryBuffer: Allow presizing block pointer list
Callers may wish to use TemporaryBuffer as an essentially unbounded
buffer by passing Integer.MAX_VALUE as the size. (This makes it
behave like ByteArrayOutputStream, only without requiring contiguous
memory.) Unfortunately, it was always allocating an array in the
backing block pointer list to hold enough blocks to MAX_VALUE--all
262,016 of them. It wasn't allocating the blocks themselves, but this
array was still extremely wasteful, using about 2MiB of memory on a
64-bit system.
Tweak the interface to specify an estimated size, and only allocate
the block pointer list enough entries to hold that size. It's an
ArrayList, so if that estimate was wrong, it'll grow. We assume the
cost of finding enough contiguous memory to grow that array is
acceptable.
While we're in there, fix an off-by-one error: due to integer division
we were undercounting the number of blocks needed to store n bytes of
data as (n / SZ).
Dave Borowitz [Tue, 17 Mar 2015 22:24:59 +0000 (15:24 -0700)]
Git: Don't close underlying repo if it came from from a caller
Since 27ae8bc65 Git has implemented AutoCloseable, which means Eclipse
may warn if close() is never called on a Git instance. For example,
the following would result in a resource warning:
Unfortunately, this construction was subtly broken: it would call both
git.close() and repo.close(), but git.close() would call repo.close()
again. Depending on the repository implementation, this might or might
not be ok. If it's not ok, it might not immediately cause an error, if
the reference count of repo was >2 at the time of closing.
Of course, explicitly calling git.close() followed by repo.close() in
two finally blocks has had the same double-closing problem since
forever. But the problem became worse when Git started implementing
AutoCloseable, because now Eclipse is _actively encouraging_
developers to change working code into broken code.
To work around this, keep track in Git's constructor of whether the
repository was passed in or opened at construction time, and only
close the repository if it was opened by Git.
Note that in the original example, there was not _actually_ a resource
leak, since repo was closed exactly once; git did not _need_ to be
closed in this case. But at least fixing this false-positive warning
no longer introduces a real bug.
Hugo Arès [Fri, 13 Mar 2015 17:57:38 +0000 (13:57 -0400)]
Make MyersDiff interruptible
For some specific file, MyersDiff goes into an infinite loop[1]. Since
this problem is hard to reproduce and possibly harder to fix, this
change makes the MyersDiff interruptible so the diff can be aborted at
least when such infinite loop happens.
When setting the parents of a commit with setParentIds() or
addParentId() it should be checked that we don't have duplicate parents.
An IllegalArgumentException should be thrown in this case.
Change-Id: I9fa9f31149b7732071b304bca232f037146de454 Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Kaloyan Raev [Fri, 6 Feb 2015 14:45:58 +0000 (16:45 +0200)]
CLI status should support --untracked-files
A special options handler is added to properly handle the short -u alias
of the option.
The "normal" mode is not supported by this patch, because this mode of
listing untracked files is not
supported by the org.eclipse.jgit.lib.IndexDiff class. This mode is not
necessary for my use case. It can be added later if anyone really needs
it.
The StatusTest is updated to cover all possible combinations of the
--porcelain and --untracked-files options.
projects / jgit.git / log