This reverts commit 6bc48cdc62.
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:
git checkout origin/master
git merge --no-ff origin/master
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>
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.
Change-Id: I511675035dcff1117381a46c294cc11aded10893
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).
Change-Id: I794eca3ac4472bcc605b3641e177922aca92b9c0
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:
Repository repo = openRepository(foo);
Git git = new Git(repo);
try {
git.someCommand().call();
} finally {
repo.close();
}
(The same warning would occur if repo were created in a try-with-
resources block.)
The "obvious" fix is to open git in a try-with-resources block:
try (Repository repo = openRepository(foo);
Git git = new Git(repo)) {
git.someCommand().call();
}
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.
Change-Id: Ie927a26ce3ae2bf8c3ef5cb963a60847067db95a
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.
[1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=444623
Change-Id: I6e006ccb122d1e68c9846a24d5399d94776c2858
Signed-off-by: Hugo Arès <hugo.ares@ericsson.com>
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>
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.
Bug: 459319
Change-Id: I305ac95739cfed0c16735e0987844e57fa27e236
Signed-off-by: Kaloyan Raev <kaloyan.r@zend.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This includes both leaving existing Change-Ids alone (as, for example
Gerrit's commit-msg hook does) and programmatically setting a value.
Change-Id: Iaaffb0107ae27de24df1f0e95a8d628fb8ea5364
This flushed out a number of bugs in the way DfsRefUpdate, or at least
the InMemoryRepository implementation, processes symrefs. These have
been fixed, to an extent, in InMemoryRepository, but other
implementations may still suffer from these bugs.
Change-Id: Ifd12115a0060b9ff45a88d305b72f91ca0472f9a
The TreeWalk(ObjectReader) constructor is explicitly to handle the case
where the caller is responsible for opening and closing the reader.
The reader should only be closed when it was created in the
TreeWalk(Repository) constructor.
Change-Id: I627681be80d69ea549f953255a64c7b3b68bcec9
The RevWalk(ObjectReader) constructor is explicitly to handle the case
where the caller is responsible for opening and closing the reader.
The reader should only be closed when it was created in the
RevWalk(Repository) constructor.
Change-Id: Ic0d595dc8d10de79e87549546c6c5ea2dc617e9b
The latest versions of the javadoc and source plugins in particular
avoid some pathological slowness I'd been seeing on Linux with Java
7 or later.
Change-Id: I9fddd7e6ef513debec5f014ed2efc4fea6917d1f
PackFile is held by the block cache and cannot be auto closed in a
try-with-resources statement. Remove the interface as JGit does
explicit management of the instances.
ObjectDatabase and RefDatabase are internal details of Repository
and are managed with the Repository. Marking them AutoCloseable
provides no value to the library or an application using the API.
Change-Id: Ibee19eadd66233e6666b601583daa1834a7778f1
Reference equality (!= or ==) cannot be used to check for
String equality. String objects are not necessarily interned
to the same instance.
Use .isEmpty() since the function only cares about an empty
string and does not need to test a specific string value.
Change-Id: If530cb59666a8196d57d2348c893706a517ea541
The %x format specifier is not valid for a byte array.
This patch fixes a bug that would cause an IllegalFormatConversionException.
Change-Id: I025975eca7b2f10bbafa39f5519f8668e6536541
Signed-off-by: David Pletcher <dpletcher@google.com>
Native git supports "git describe --long". This will enforce returning a
long description of a commit even if a tag is directly pointing to the
commit (in contrast to just returning the tag name as it is now). This
commit teaches JGits DescribeCommand and the describe command in the pgm
package to support "--long".
Bug: 460991
Change-Id: I65e179b79e89049c6deced3c71cb3ebb08ed0a8f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The index provides access to a list of objects in a pack.
This will be helpful for repository integrity checking.
Change-Id: I435eeeb3fe1b1f5632d40528936416e97491d412
Signed-off-by: David Pletcher <dpletcher@google.com>
This hook uses the file .git/COMMIT_EDITMSG to receive and potentially
modify the commit message.
Change-Id: Ibe2faadfb5d3932a5a3da2252d8156c4c04856c7
Signed-off-by: Laurent Delaigue <laurent.delaigue@obeo.fr>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Hooks are now obtained via a convenient API like git commands, and
callers don't have to check for their existence.
The pre-commit hook has been updated accordingly.
Change-Id: I3383ffb10e2f3b588d7367b9139b606ec7f62758
Signed-off-by: Laurent Delaigue <laurent.delaigue@obeo.fr>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This allows for testing arbitrary sets of push/fetch hooks (e.g.
PreReceiveHook) without depending on either an external protocol (e.g.
HTTP) or the local filesystem.
Change-Id: I4ba2fff9c8a484f990dea05e14b0772deddb7411
TransportLocal knows how to spin up a thread to allow two repositories
in the same process to communicate using the wire protocol. However,
it is still tied to local on-disk filesystems, and needs to be able to
fork processes if not using the default git-{upload,receive}-pack
implementation.
Extract out the connection classes so they can be used by other
transport implementations.
Change-Id: I5db59086740735508c2e70a597c2d1a89014b072
* stable-3.7:
Prepare 3.7.1-SNAPSHOT builds
JGit v3.7.0.201502260915-r
Read user.name and email from environment first
Provide more details in exceptions thrown when packfile is invalid
Change-Id: I427f861c6bc94da5e3e05dbbebbf0ad15719a323
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Matthias Sohn
Jonathan Nieder
Dave Borowitz
Christian Halstrick
Hugo Arès
Kaloyan Raev
Shawn Pearce
Markus Duft
Matthew Spurrier
David Pletcher
Laurent Delaigue