For example with following URL,
amazon-s3://.jgit@mybucket/foo.git
if ~/.jgit is missing, jgit command will throw a NullPointerException.
With this patch, a reasonable error message will be emitted:
fatal: Cannot read file /Users/jamesyonan/.jgit
Change-Id: I1d366f2d55e170d2972715c657c8e2d10c8d87d2
Signed-off-by: James Yonan <james@openvpn.net>
Read options that control squashing, whether or not to commit the merge
and regarding fast forwarding from the configuration and use them if no
explicit values for these options have been provided to MergeCommand.
Change-Id: Ifdaed4b5e4adc142657c03c8e78b709a99eeddbd
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When the caller specifies to JGit in advance that a ref-update is a
non-fast-forward update, and that those are permitted, we should never
need to call the potentially expensive isMergedInto() check. Re-checking
that the older commit is /not/ reachable from the newer is superfluous.
http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg02258.html
Change-Id: I4bbf593de4dcea6b6f082881c1a33cb3a6a7fb89
Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com>
Formerly the 4-arg constructor did not do this, which was unfortunate
as that constructor's the only way for an external user of JGit to set
the /type/ of the ref-update - which you might want to do to indicate
that the update is expected to be a UPDATE_NONFASTFORWARD, and thus does
not require expensive isMergedInto() calculations:
http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg02258.html
Change-Id: I84c5e4927131e105bed93e31a62da6367c78de32
Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com>
When no explicit value is set via FetchCommand.setRemoveDeletedRefs()
checks if pruning is enabled in the configuration.
The following commit introduced the prune config to C Git:
737c5a9cde
Change-Id: Ida79d335218e1c9f5c6e2ce03386ac8a1c0b212e
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Java normalizes paths to NFC, but other source may not, e.g Eclipse.
Bug: 413390
Change-Id: I08649ac58c9b3cb8bf12794703e4137b1b4e94d5
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
If there is an unnormalized symbolic link in the index, lie that it
matches a normalized link in the working tree. This does not make the
case completely invisible everywhere though, but it helps to some
degree.
Change-Id: I599fb71648c41fa2310049d0e0040b3c9f09386b
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
On Windows the length reported by FileAttributes is the size
of the target file (a bug, I guess) rather than the link,
so we read the linke and look at the length of the link instead.
Bug: 353771
Change-Id: I834b06d0447f84379612b8c9190fa77093617595
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The "cut off" optimization causes it to not include branches that
contain the specified commit but happen to share commits with a branch
that does not contain the commit.
An example:
-B foo
\
-A---C master
findBranchesReachableFrom for commit A with both branches as input may
not return master (depending on the order of the input). The reason is
that A is not contained in foo, and therefore the old code would put B
in the cutOff set. When then walking the master commits and B is
checked, it is found in the cutOff set and the walk is aborted, causing
master not to be returned even though it should.
Bug: 425674
Change-Id: I2c0c406ce5fcc9a03538b483473af930d4895d30
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The change includes comparing symbolic links between disk and index,
adding symbolic links to the index, creating/modifying links on
checkout. The behavior is controlled by the core.symlinks setting, just
as C Git does. When a new repository is created core.symlinks will be
set depending on the capabilities of the operating system and Java
runtime.
If core.symlinks is set to true, the assumption is that symlinks are
supported, which may result in runtime errors if this turns out not to
be the case.
Measuring the cost of jgit status on a repository with ~70000 files,
of which ~30000 are tracked reveals a penalty of about 10% for using
the Java7 (really NIO2) support module.
Bug: 354367
Change-Id: I12f0fdd9d26212324a586896ef7eb1f6ff89c39c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
We should really pass the forceContentCheck parameter to
the real method.
Change-Id: I9ea439cf6340a18d0e931edde3b9e3486cafde93
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Johannes Carlsson identified a race condition[1] that can lead to
spurious MissingObjectExceptions at read time. If two threads are
active inside of ObjectDirectory looking for a packed object and the
packList is currently the empty NO_PACKS list, thread A will find
no object and eventually consider tryAgain1(). If thread A is put
to sleep and this point and thread B also does not find the object,
loads the packs, when thread A wakes up its tryAgain1 would return
false and the thread never considers the packs.
Rework the internal API of ObjectDirectory to keep a handle on the
exact PackList that was iterated by thread A, allowing it to always
retry walking through the packs if the new PackList is different.
This had some ripple effect into the CachedObjectDirectory and
the shared FileObjectDatabase interface. The new code should be
slightly easier to follow, especially from the perspective of the
CachedObjectDirectory trying to minimize the number of open system
calls it makes to files matching "$GIT_DIR/objects/??/?x{38}".
[1] http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg02401.html
Change-Id: I9a1c9d6ad6cb38404b7b9178167b714077561353
This version does not attempt to unsmudge, unlike the first attempt
in Idafad150553df14827eccfde2e3b95760e16a8b6.
Bug: 372834
Change-Id: I9300e735cb16d6208e1df963abb1ff69f688155d
Also-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Robin Stocker <robin@nibor.org>
In certain cases a JGit server updating an existing shallow client
selected a common ancestor that was behind the shallow edge of
the client. This allowed the server to assume the client had some
objects it did not have and allowed creation of pack deltas the
client could never inflate.
Any commit the client has advertised as shallow must be treated
by UploadPack server as though it has no parents. With no parents
the walker cannot visit graph history the client does not have,
and PackWriter cannot consider delta base candidates the client
is lacking.
Change-Id: I4922b9354df9f490966a586fb693762e897345a2
The folder .git/rebase-merge was not removed in this case. The
repository was then still in rebase state, but neither abort nor
continue worked.
Bug: 425742
Change-Id: I43cea6c9e5f3cef9d6b15643722fddecb40632d9
To correspond to the behavior of "git branch", also return HEAD in case
it is detached.
Bug: 425678
Change-Id: Ie615731434d70b99bd18c7a02e832c0a2c3ceef3
Signed-off-by: Robin Stocker <robin@nibor.org>
Package was renamed, so I had to update the imports. Also, I verified
bitmap serialization was still compatible.
Change-Id: I161ad3875b963b56001beab477ef8d072accee4f
When encountering a submodule entry, "jgit archive" tries to write its
content verbatim as an entry to the archive, which fails with a
JGitInternalException wrapping a MissingObjectException because the
submodule repository commits are typically not part of the
superproject.
When a subproject is available (for example because it has been
checked out as a subdirectory of a superproject worktree), it would be
nice to recurse into it and make one archive recording the state of
the entire project. Unfortunately sometimes the subproject is not
available or it can be hard to find (e.g., it can be on another
server). Even when some subprojects are available, "jgit archive"
should not produce different output for the same tree depending on
which subprojects it has easy access to, so there is no obvious good
default behavior that recurses without relying on access to all
subprojects.
Instead, replace each submodule entry with a placeholder empty
directory. "git archive" does the same.
Change-Id: I1295086037b77fc948b3f93c21d47341e25483e5
Signed-off-by: Jonathan Nieder <jrn@google.com>
Entries for directories are optional and mostly wasted space in most
archive formats (except as a place to hang ownership and filesystem
permissions), but "git archive" includes them. Follow suit.
This will make it easier in a later change to include empty
directories as placeholders for missing submodules.
Change-Id: I1810c686bcc9eb4d73498e4d3e763e18787b088a
Signed-off-by: Jonathan Nieder <jrn@google.com>
This reverts commit 1def0a1257.
We found this fix uncovers problems with unsmudged DirCacheEntry's. This
surfaced because egit's ui test CreatePatchActionTest failed since jgit
computes a wrong status. JGit doesn't detect modified content in now
unsmudged entries. Hence revert this change until these problems are
fixed.
Change-Id: Ia04277ce316d35fc5b0d82c93d2078b856af24bb
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Common practice when distributing tarballs is to prefix all entries
with a single directory name so when the tarball is extracted it all
falls neatly into a single directory. Add a setPrefix() method to
ArchiveCommand to support this.
Change-Id: I16b2832ef98c30977f6b77b646728b83d93c196f
Signed-off-by: Jonathan Nieder <jrn@google.com>
This is the case for submodules in .git/modules, which typically have a
worktree config of "../../../dir". This can confuse callers, which e.g.
try to call Repository.stripWorkDir with it.
Bug: 423644
Change-Id: I0c00953f73f9316a66d0fc10eab52d8779c88f00
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This came up while testing the proposed buck build for jgit. With buck
we can introduce smaller modules to allow for more concurrency during
build and to better control inner structure of jgit. Trying to put the
porcelain API into a different module than lower level implementation
classes failed since RebaseTodoLine used a porcelain API exception
causing a dependency cycle on the proposed modules. Using an exception
defined on the same abstraction level fixes this problem.
Change-Id: I26a5353e1a8fc23e67d8ce61309bd964f7665bcb
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
These methods allow to find all configuration entry names for a given
section or section/subsection searching recursively through all base
configurations of the given configuration.
These methods are needed to calculate the names for the effective
configuration of a git repository which combines the configuration entry
names found in the repository, global and system configuration files
Bug: 396659
Change-Id: Ie3731b5e877f8686aadad3f1a46b2e583ad3b7c6
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This feature was introduced in native git with version 1.8.4.
Bug: 422951
Change-Id: I42f194174d64d7ada6631e2156c2a7bf93b5e91c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Instead of just a generic "Invalid path: $path", add a reason for the
cases where it's not obvious what the problem is (e.g. "aux" being
reserved on Windows).
Bug: 413915
Change-Id: Ia6436bd2560e4f049c92d9aac907cb87348605e0
Signed-off-by: Robin Stocker <robin@nibor.org>
The matcher has to be reset before using it, as was already done in the
other cases.
Bug: 423039
Change-Id: I87abaa7ad7f0aac8651db6e88d41427cacb4d776
Also-by: Ondrej Vrabec <ovrabec@netbeans.org>
Signed-off-by: Robin Stocker <robin@nibor.org>
When there are conflicts with a recursive merge, the conflicting paths
are stored in unmergedPaths (field in ResolveMerger). Later, when the
MergeResult is constructed in MergeCommand, getBaseCommit is called,
which computes the merge base a second time.
In case of RecursiveMerger, getBaseCommit merges the multiple merge
bases into one. It does this not by creating a new ResolveMerger but
instead calling mergeTrees. The problem with mergeTrees is that at the
end, it checks if unmergedPaths is non-empty and returns false in that
case.
Because unmergedPaths was already non-empty because of the real merge,
it thinks that there were conflicts when computing the merge base again,
when there really were none.
This can be fixed by storing the base commit when computing it and then
returning that instead of computing it a second time.
Note that another possible fix would be to just use a new ResolveMerger
for merging the merge bases instead. This would also remove the need to
remember the old value of dircache, inCore and workingTreeIterator (see
RecursiveMerger#getBaseCommit).
Bug: 419641
Change-Id: Ib2ebf4e177498c22a9098aa225e3cfcf16bbd958
Signed-off-by: Robin Stocker <robin@nibor.org>
Bad files from symbolic links were being generated on Cygwin and
required resolution by the appropriate FS. Pass FS to getSymRef and call
FS.resolve before asking if the file is absolute.
Bug: 419494
Change-Id: I74aa7a285954cade77f41df6f813b6dafb5d6cd7
Signed-off-by: John Ross <jwross@us.ibm.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
With this change jgit checks for uncommitted changes before a rebase is
started. This is also done by native git. One reason is that an abort
would override such changes. The check is skipped for a non-interactive
rebase when it will result in a fast-forward. In this case there can be
only checkout conflicts but no merge conflicts, so there cannot be an
abort which overrides uncommitted changes.
Bug: 422352
Change-Id: I1e0b59b2a4d80a686b67a6729e441924362b1236
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
JGit was not handling certain file/folder conflicts during a checkout
correctly. This was reported by Axel Richard in
http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg02358.html.
This commit fixes this problem.
Still JGit behaves intentionally different than native git.
If HEAD contains a tree, and workingtree, Index and Merge contain a file
with same content ... then JGit allows a conflict free checkout of
Merge. Native git always complains that it doesn't want to overwrite
local changes. But there is no need to update the working tree because
Index and Merge are already equal.
A shell script which shows how native git behaves can be found here.
https://gist.github.com/chalstrick/7694959#file-gistfile1-sh
Change-Id: Ifd6a68974d61cd4fa23bc575f3a40773db66cafc
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
James Yonan
Konrad Kügler
Roberto Tyley
Robin Rosenberg
Robin Stocker
Shawn Pearce
Christian Halstrick
Matthias Sohn
SATO taichi
Stefan Lay
Tomasz Zarna
Colby Ranger
Jonathan Nieder
John Ross