This behavior was defined in the Javadoc of PathEdit, but not actually
implemented.
It's necessary when one wants to use a PathEdit to check out a specific
stage in apply.
Bug: 390147
Change-Id: Iaed5cf60c554fc17e6c4d188caf4f0231da920d0
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
Change-Id: I458167739210214fa54c4b3d62fac5abc82f96f7
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
The test checks if an error is thrown when trying to create the same tag
for the second time.
Change-Id: I4ed2f6c997587f0ea23bd26a32fb64a2d48a980e
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
With bug 391855, PathEdit will be changed to apply an edit for each
stage. With that, CommitCommand would no longer work correctly when
committing an unmerged path.
This changes it to use a DirCacheBuilder which allows us to correctly
replace the entries for the three stages with one, which is not possible
with PathEdit.
Bug: 391859
Change-Id: I6dc180aec7e2cbf8d1e91f50482c95bc420f79de
The DfsPackFile will fire any static repository listeners on the event
just before the PackIndex is loaded.
Change-Id: Ie51098106bd5a1a32feae7d2dd068abf02b030ee
With bug 391855, DirCacheEditor's PathEdit will be applied for each
stage. For an unmerged path, this would result in 3 equal entries for
the same path.
By using a DirCacheBuilder, the code is simpler and does not have the
above problem with unmerged paths.
Bug: 391860
Change-Id: I785deeaeb8474f8c7a7fbc9ef00d3131fac87e41
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
The previous implementation used a PathEdit, which does not reset the
stage of the entry.
Bug: 391860
Change-Id: If26d3a35abfee85424ad69de724f06a28b6e9efb
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
These appear as descriptions in the index, see here (currently empty):
http://download.eclipse.org/jgit/docs/latest/apidocs/
Change-Id: If7996deef30ae688bade8b3ad6b19547ca3d8b50
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
The API was changed to not allow null values anymore with
I0ac994ae8e47789d38f7c6e6db55d482f0f1bac3, leading to an IAE.
Bug: 393054
Change-Id: If33560ae976b46a02ff75b2e4ec05c13a8ad2d41
For streams that should not be closed, i.e. don't own an underlying
stream, and in-memory streams that do not need to be closed we just
suppress the warning. This mostly apply to test cases. GC is enough.
For streams with external resources (i.e. files) we add the necessary
call to close().
Change-Id: I4d883ba2e7d07f199fe57ccb3459ece00441a570
If a client attempts to create a branch that already exists on the
remote side, tell them "already exists" rather than repeat lots of
information about the reference. Previously the error looked like:
! [remote rejected] tags/1.3.1 -> 1.3.1 (Ref Ref[refs/tags/1.3.1=e3857ee05...] already exists)
Now it will simply say:
! [remote rejected] tags/1.3.1 -> 1.3.1 (already exists)
Change-Id: I96fc67ca8b650052de6e662449a3c5bc8bbc010b
In code review we often see uses of JGitInternalException where a high
level GitAPIException would be more appropriate. Hopefully the word
low-level in the constructor comment will lead to fewer such cases.
Change-Id: Id5ec7897535f6c5c5f0bd153fe0ff15c65083474
toExternalString, equals and hashCode don't expect them to be null, so
explicitly disallow it in the constructor.
Also fix the documentation of setAuthor and setCommitter in
CommitCommand when specifying name and email as separate arguments.
Bug: 352984
Change-Id: I0ac994ae8e47789d38f7c6e6db55d482f0f1bac3
In Iff768422c the offset used for the content id was fixed to use the
offset that applied to the dircache iterator. Unfortunately the index
for the dircache content id offset stuck for entries that were not in
the index. Few caller probably cared about that, unless it actually
caused an ArrayIndexOutOfBoundsException.
Change-Id: Ic9f0e77c8ea3a0770d88565e94392e76853e3006
Change-Id: I07aca821010daca75a66506b9ca738bc8c262abb
Signed-off-by: Markus Keller <markus_keller@ch.ibm.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Makes it much easier to debug the results of
OperationResult#getTrackingRefUpdates (which otherwise requires digging
into a TreeMap structure).
Change-Id: I90da5385ee47c441404728f252eb3a100c48ee1c
Valid refs are defined by git-check-ref-format(1). In addition
we will not try to perform a lookup of an invalid ref name in
Repository.resolve().
Reported by R Shapiro in the Eclipse JGit Forum.
Change-Id: I0b098eec9ecb98a9ce16b1cfb476729aaf2fb190
Without this check, the checkout was done but the result was a "both
deleted" status when inspecting it with C Git.
Found this while working on bug 390147.
Change-Id: Ic3693f2c651827239e838bf7f37da842a7ae9707
Clarify expiration of objects with the modification time exactly at the
given time instant.
Change-Id: I2000aec89c8d6a95700380b0a32275d2d658f67e
Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>
This prevents a lot of unnecessary warnings about disouraged usage of
the org.eclipse.jgit.internal package within JGit itself.
Change-Id: Ia6683902809425fd7245e7d5d344c2ff8f317ebb
resolve("foo~X") where X is greater than the distance from foo to the
root should return null, but 2a2362fb introduced a bug causing it to
either return resolve("foo") or NPE. Add a test for the correct
behavior.
Also add an analogous test for foo^X where X is greater than the
number of parents (which was not broken by that commit).
Change-Id: Ic580081ece57c8c2df29b652897b425ecb34e11f
For configuration parameter like "gc.pruneexpire" we need to understand
the value "never". Never is handled as a date so far into the future
that it will never happen. The actual value currently used is the
constant GitDateParser.NEVER.
Change-Id: I7744eaee9bf5026da517151c212c88325c348d6c
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Instead of just returning null when something was not parseable we
should throw a real ParseException. This allows us to distinguish
between specifications which are unparseable and those which represent
no date (e.g. "never")
Change-Id: Ib3c1aa64b65ed0e0270791a365f2fa72ab78a3f4
Make GC honor the config parameter gc.pruneexpire. If the parameter is
not set then the default is "2.weeks.ago"
Change-Id: I0ae0ca85993cafb4bc75ba80504da18544894ec3
Change-Id: Id5b578f7040c6c896ab9386a6b5ed62b0f495ed5
Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The underlying problem is that System.out is a PrintWriter and
as such it does not throw exceptions on error, but rather just
sets a flag and continues.
This changes replaces the use of System.out with a PrintWriter-like
writer that does not catch error, but instead throw them to the
caller.
Bug: 366243
Change-Id: I44405edc4416e943b87f09a0f6ed041c6c51b046
Change-Id: I98fc9720106bcd873b330090bafde276508f8a40
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
ResolveMerger throws a MissingObjectException when it encounters
a submodule conflict while merging. The reason is that it treats
the submodule link as a blob and tries to read its contents.
We solve the issue by detecting before content merge whether the
path to be merged is a submodule link, and skip the content
merge if it is.
Bug: 389238
Change-Id: I9a58dfc7716b28a21f5c04cf3a865091ae8dfe7e
Signed-off-by: Tommi Siivola <tommi.siivola@eficode.com>
The value of -1 is the default value used by the underlying http
transports provided by the jre. On some versions an attempt to
set the timeout explicitly to -1 triggers a check condition,
disallowing negative numbers.
Bug: 389003
Change-Id: I74a22f8edc6c8e15843ad07c96a137739d9dcad1
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
None of these should have been exposed to base classes. The majority
of them are private implementation details that are not required by a
subclass in order to interact with the base protocol definition. The
few that are needed should be visible as accessor methods, so the
internals can be modified without breaking the public JGit API.
Change-Id: I874179105c9c37703307facbbf99387c52bf772c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This flag was added to provide an unsafe operation on the local
repository because the storage.dht code was too damn slow to provide
proper safe Git behavior all of the time. Now that stoarge.dht has
been removed from the repository, also delete this unsafe flag to
prevent applications from misusing the JGit library and permitting
users to potentially damage their local repository with bad data
received from an untrusted peer.
Change-Id: Ib1861c48bb74836731e7b7d57b635dd654b0dc66
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When a file is not in the index and neither contents nor mode differ
between "head" and "merge", the index state should be kept. If they
differ, a checkout conflict should occur. This is described in Git's
git-read-tree.txt.
JGit used to replace the index state with "merge" in both of the above
cases.
A confusing effect of this was that when one removed a file and then did
a rebase, the file silently reappeared again.
The changes to dir/file conflict handling are a consequence of this
change, as the index handling change made tests in DirCacheCheckoutTest
break. I compared these cases to C Git and the new behavior there also
matches what C Git does.
Bug: 387390
Change-Id: I5beb781f12172a68f98c67d4c8029eb51ceae62d
Signed-off-by: Robin Stocker <robin@nibor.org>
The transformation is the same as AutoCRLFOutputStream does, but
the direction is reversed. The tests are reused, but the implementation
derives somewhat from the EolCanonicalizingInputStream.
This stream will be used to compare blobs with LF line endings with
worktree data that has CRLF line endings.
Bug: 387501
Change-Id: I80d96e453e7f780dd464a89778de124cf35384e1
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Robin Stocker
Matthias Sohn
Tomasz Zarna
Colby Ranger
Robin Rosenberg
Shawn O. Pearce
Markus Keller
Marc Strapetz
Sasa Zivkov
Dave Borowitz
Christian Halstrick
Tommi Siivola
Jason Pyeron
Tomasz Zarna