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>
The statistics for a repo now expose how many bytes are used in the
filesystem to store all loose/packed objects. The number of packed/loose
refs are also exposed.
Change-Id: I335a4c7630a2629a86f13a2a5cd99f79a2c2afa4
In order to parse user specified strings containing date and time info
a thread-safe parser is implemented. This is needed for example to
interpret configuration parameters (e.g. gc.pruneexpire where need to
parse strings like "2 weeks ago"). The parser is thread-safe by caching
SimpleDateFormat instances in a ThreadLocal cache.
Native git has a parser called approxidate which is able to interpret a
huge number of formats ("1 year ago", "tea time", ...). Ideally JGit
should be able to parse the same strings as native git but for now this
parser understands the following subset:
"now"
"yesterday"
"(x) years|months|weeks|days|hours|minutes|seconds ago"
"yyyy-MM-dd HH:mm:ss Z" (ISO)
"EEE, dd MMM yyyy HH:mm:ss Z" (RFC)
"yyyy-MM-dd"
"yyyy.MM.dd"
"MM/dd/yyyy"
"dd.MM.yyyy"
"EEE MMM dd HH:mm:ss yyyy Z" (DEFAULT)
"EEE MMM dd HH:mm:ss yyyy" (LOCAL)
Change-Id: Iccb66dadb60da13104e73140e53d5e2de068369c
EGit should be able to continue a rebase started by C Git.
Change-Id: I63058026295fec34157b5687ae87ae9cb0c27c86
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Java has no option but to use precomposed Unicode, so we should
state that when creating a new repository. Not that Java will use
precomposed unicode regardless of this setting, but this reduces
the risk of incompatibility with C Git.
Change-Id: I3779b75f76d2e2061c836cbc9b4b7c2ae0cf18f4
JGit was not able to lookup refs which had the name of files which exist
in the .git folder. When JGit was looking up a ref named X it has a
fixed set of directories where it searched for files named X
(ignore packed refs for now). First directory to search for is .git. In
case of the ref named 'config' it searched there for this file, found it
(it's the .git/config file with the repo configuration in it), parsed
it, found it is an invalid ref and stopped searching. It never looked
for a file .git/refs/heads/config.
I changed JGit in a way that when it finds a file in GIT_DIR which
corresponds to a ref name and if this file doesn't contain a valid ref
then it will ignore the InvalidObjectIdException and continue searching.
Change-Id: Ic26a329fb1624a5b2b2494c78bac4bd76817c100
Bug: 381574
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
The method uses some heuristics to obtain much better performance
than isMergeBase.
Since I wrote the relevant code in the method I approve the license
change from EPL to EDL implied by the move.
Change-Id: Ic4a7584811a2b0bf24e4f6b3eab2a7c022eabee8
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
EGit wasn't able to decorate local branches tracking another local
branch with number of commits the checked out local branch differs from
the other local branch it's tracking.
Bug: 376970
Change-Id: I74e932d5eacd74dbf6b0dffcfc65ba3222a8250e
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
On conflicts in rebase or cherry-pick, the conflict markers were like
this:
<<<<<<< OURS
a
=======
b
>>>>>>> THEIRS
This is technically correct, but it could be better.
It's especially confusing during a rebase, where the meaning of
OURS/THEIRS is not obvious. The intuition is that "ours" is the commits
that "I" did before the rebase, but it's the other way around because of
the way rebase works. See various bug reports and stackoverflow
discussions.
With this change, in the case of a cherry-pick while on master, the
markers will be like this:
<<<<<<< master
a
=======
b
>>>>>>> bad1dea Message of the commit I'm cherry-picking
In the case of a "git rebase master":
<<<<<<< Upstream, based on master
a
=======
b
>>>>>>> b161dea Message of a commit I'm rebasing
It's not "master" because that would only be correct for the first
cherry-pick during a rebase, after that, it's master + already
cherry-picked commits.
And in the case of a "git pull --rebase":
<<<<<<< Upstream, based on branch 'master' of git@example.org:repo
a
=======
b
>>>>>>> b161dea Message of a commit I'm rebasing
Bug: 336819
Change-Id: I1333a8dd170bb0077f491962013485efb6f2a926
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The file location of the constructor for BlameGenerator
did not specify where the path should be relative from.
Fix BlameGenerator comments based on suggestions by Robin Stocker.
Change-Id: I3d79db2d2ba4961835fe664ae6178e0bfc97b910
Robin Stocker
Shawn O. Pearce
Robin Rosenberg
Markus Keller
Marc Strapetz
Sasa Zivkov
Matthias Sohn
Dave Borowitz
Christian Halstrick
Tommi Siivola
Jason Pyeron
Tomasz Zarna
Patrick Carlson