If the header and trailer are identical up to a single line on both
sides, return that REPLACE edit as the only result. No algorithm can
break down a REPLACE with height of 1.
Change-Id: I483c40e8790cc3e8b322ef6dfce2299491fd0ac7
With this commit running blame on render_view_impl.cc[1] saves
about 644 ms over prior versions, reducing the time about 4.5%.
Large projects often contain strands of commits where no changes
are made to a particular subtree. Blame used to dive recursively
into these subtrees to look for the blob and check if its SHA-1
was changed. In chromium/src[1] only 20% of the commits modify
the content/renderer subtree relevant for the file.
The recursivePath is necessary to check for '/' and remember
if common subtree elimination should be attempted. When a file
lives within a subtree the extra cost to check for unmodified
subtrees saves time. However for files in the root tree the
extra work incurred by TreeWalk is not worthwhile and would
significantly increase overall running time.
Now typical running times from an otherwise idle desktop:
real 0m13.387s 0m13.341s 0m13.443s
user 0m15.410s 0m15.220s 0m15.350s
previously:
real 0m14.085s 0m14.049s 0m13.968s
user 0m15.730s 0m15.820s 0m15.770s
[1] 34d6e5c5b4/content/renderer/render_view_impl.cc
Change-Id: Ib16d684df7ffa034ee28def3fb22c797998d5b7b
Avoid converting the raw mode to FileMode. This is an expensive
if-else-if sort of test to just check if the thing is a blob.
Instead test the bit mask directly, which is at least a few
instructions shorter.
The TreeWalk is already recursive and will auto-dive into any
subtrees found. isSubtree check is unnecessary, as is the loop,
as only one result will ever be returned by next().
Change-Id: I9fb25229ebed857469427bfbdf74aedebfddfac8
Ensure commit object names are unique by extending the default
abbreviation as long as necessary. This allows `jgit blame` to
more closely match the formatted output of `git blame` on large
histories like Gerrit Code Review's ReceiveCommits.java file.
Change-Id: I5f7c4855769ee9dcba973389df9e109005dcdb5b
Problem:
The BlameGenerator used the RevFlag SEEN to mark commits it had
already looked at (but not necessarily processed), to prevent
processing a commit multiple times. If a commit is a conflicting
merge that contains lines of the merge base, that have been deleted
in its first parent, either these lines or the lines untouched
since the merge base would not be blamed properly.
This happens for example if a file is modified on a main branch in an
earlier commit M and on a side branch in a later commit S. For this
example, M deletes some lines relative to the common base commit B,
and S modifies a subset of these lines, leaving some other of these
lines untouched.
Then side is merged into main, creating a conflict for these
lines. The merge resolution shall carry over some unmodified lines
from B that would otherwise be deleted by M. The route to blame
these lines is via S to B. They can't be blamed via M, as they
don't exist there anymore.
Q
|\
| \
| S
| |
M |
| /
|/
B
Blaming the merged file first blames via S, because that is the
most recent commit. Doing so, it also looks at B to blame the
unmodified lines of B carried over by S into the merge result. In the
course of this, B is submitted for later processing and marked SEEN.
Later M is blamed. It notices that its parent commit B has been
SEEN and aborts processing for M. B is blamed after that, but only
for the lines that survived via S.
As a result, only the lines contributed by S or by B via S are
blamed. All the other lines that were unchanges by both M and S,
which should have been blamed to B via M, are not blamed.
Solution:
Don't abort processing when encountering a SEEN commit. Rather add the
new region list of lines to be blamed to those of the already SEEN and
enqueued commit's region list. This way when the B commit of the
above example is processed, it will blame both the lines of M and S,
yielding a complete blame result.
Bug: 374382
Change-Id: I369059597608022948009ea7708cc8190f05a8d3
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Shawn Pearce <spearce@spearce.org>
This should make it possible for the gitiles plugin to register its
archive formats after gerrit has already registered them.
Signed-off-by: Jonathan Nieder <jrn@google.com>
Change-Id: Icb80a446e583961a7278b707d572d6fe456c372c
* stable-3.3:
Ensure that stored credentials aren't reset too early
Change-Id: Idcd57e12f5fe905952be49edb4f82db6b7ed469f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Some commands are started without showing a dialog allowing to enter
credentials if needed. Hence we need to tolerate one failing HTTP
authentication to trigger loading credentials from the secure store.
Hence we should not immediately reset the stored credentials if the
first attempt to authenticate fails.
Bug: 431209
Change-Id: I1b9fa34c3d70be226bb1c59c9ebe995998d29bc8
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When safeForMacOS is enabled the checker verifies a name does not
match against another name in the same tree after normalization to
NFC. The check was incorrect and failed when the first name was put
in, rejecting simple trees containing only one file like "F".
Add a test for this simple tree to verify it is accepted.
Fix the test for NFC normalization to actually normalize
and have a collision.
Change-Id: I39e7d71150948872bff6cd2b06bf8dae52aa3c33
"Invalid tree aa6f10291050a00de83b4630783030b9e3b969ec:duplicate entry names"
is hard to read. A space after the object name and before the message
makes the message more readable.
Change-Id: I96406100dbef8e4bc8fe2047d102681194dc8847
When working on a non-bare repository with a detached HEAD jgit's GC was
packing the ref named "HEAD" into the packed-refs file and deleted the
loose ref (the file .git/HEAD!). This made the repo unusable for native
git. This is fixed by telling jgit to only pack refs starting from
"refs/"
Change-Id: I50018aa006f18b244d2cae2ff78b5ffe1b821d63
Previously, calling addAnnotatedTags() did not modify any state when
there were no annotated tags in the repository. This caused the code
to assume no addFoo() methods had been called, and fell back to the
default of adding refs/*. Instead, use null to indicate neither
addRefs() nor addAnnotatedTags() was called.
Add a test for this behavior.
Change-Id: I9926e5ac17e1a983cd399798993031c72bd79c2c
* stable-3.3:
Prepare 3.3.2-SNAPSHOT builds
JGit v3.3.1.201403241930-r
Retry to call credentials provider if http authentication failed
Ensure that ssh authentication is retried only in JGit
[findBugs] Ensure streams are closed in a finally block
Update com.jcraft.jsch to 0.1.50 also in pom dependencies
Change-Id: I45b48a3f2dc8c7708e9518645d72bc5645002836
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Under certain circumstances isMergedInto() returned
false even though base is reachable from the tip.
This will hinder pushes and receives by falsely
detecting "non fast forward" merges.
o---o---o---o---o
/ \
/ o---o---A---o---M
/ /
---2---1-
if M (tip) was compared to 1 (base), the method
isMergedInto() could still return false, since
two mergeBases will be detected and the return
statement will only look at one of them:
return next() == base;
In most cases this would pass, but if "A" is
a commit with an old timestamp, the Generator
would walk down to "2" before completing the
walk pass "A" and first finding the other
merge base "1". In this case, the first call to
next() returns 2, which compared to base evaluates
as false.
This is fixed by iterating merge bases and
returning true if base is found among them.
Change-Id: If2ee1f4270f5ea4bee73ecb0e9c933f8234818da
Signed-off-by: Gustaf Lundh <gustaf.lundh@sonymobile.com>
Signed-off-by: Sven Selberg <sven.selberg@sonymobile.com>
If the user provided wrong credentials or credentials changed we
shouldn't give up immediately but retry to get valid credentials from
the credentials provider. Reset the credentials provider if
authentication failed to avoid it reuses wrong credentials in
case it stored them in a persistent store.
Bug: 338048
Bug: 342592
Bug: 427735
Change-Id: Ibd62ef3da17be6454991c43f524c8bbc7ca3c37e
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
JGit wants to control retries during ssh authentication. But JSch by
default already retries 6 times. Hence disable retries in JSch. Without
this the credentials provider isn't reset if e.g. wrong credentials are
specified.
Bug: 430210
Change-Id: I6fa726a14a84b06411e7010608c7a1e2bfb8bfe8
When more than one lane is drawn, some commits are vertically misaligned
(off by two pixels). This change fixes the alignment.
Bug: 426047
Change-Id: Icbe7ce9f5a6b281b2aaab66e4d76dfc1010b2fb5
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Rüdiger Herrmann <ruediger.herrmann@gmx.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Copying flags through a graph with deep side branches can cause
StackOverflowError. The recursive step to visit the 2nd parent of
a merge commit can overflow the stack if these are themselves very
deep histories with many branches.
Rewrite the loop to iterate up to 500 recursive steps deep before
unwinding the stack and running the remaining parts of the graph
using a dynamically allocated FIFORevQueue.
This approach still allows simple graphs that mostly merge short
lived topic branches into master to copy flags with no dynamic
memory allocation, relying only on temporary stack extensions.
Larger more complex graphs only pay the allocation penalities
if copying has to extend outwards "very far" in the graph, which
is unlikely for many coloring based algorithms.
Change-Id: I1882e6832c916e27dd5f6b7602d9caf66fb39c84
Verifying 100 new objects are fully connected to the existing DAG
is usually very cheap. Checking the entire Linux kernel history is
fully connected when pushing it to a new repository can take 30-60
seconds. Display a progress counter during this time so the client
knows the server is still working.
Change-Id: Iababe3ee1d35cb82f2bef2f12da7a2ecd03282b0
* changes:
Allow configuration of receive pack's ObjectChecker through fsck.*
Correct fetch to use fetch.fsckObjects and transfer.fsckObjects
Default receive.fsckObjects to transfer.fsckObjects
Allow ReceivePack callers to configure their own ObjectChecker
Check for duplicate names after folding case in ObjectChecker
Change DirCacheCheckout to verify path using ObjectChecker
Reject mixed case .git on Mac OS in ObjectChecker
Reject special Windows device names in ObjectChecker
Allow an ObjectChecker to reject special characters for Windows
Reject '.git' as a tree name in ObjectChecker
Extract path segment check function in ObjectChecker
Permit ObjectChecker to optionally accept leading '0' in trees
fsck.allowLeadingZeroFileMode may be set true to permit pushing
broken trees with leading '0' in the file mode.
fsck.safeForWindows may be set true to require new trees to have
only file names that are safe on the Windows platform.
fsck.safeForMacOS may be set true to require new trees to have
only file names that do not cause collisions or confusion on the
Mac OS platform.
Change-Id: I1a225c1b3cd13c0d1a0d43fffe79355c501f49b7
git-core configures fsck during fetch using these two variables.
JGit use of fsck in fetch predates the usage in git-core and had
reused receive.fsckobjects, which does not match behavior.
Change-Id: Ie4d5f082258c4b2928c7ecc3780c6363fa587f34
ReceivePack should configure itself with receive.fsckObjects,
and if not defined, transfer.fsckObjects. This is the order
used by git-core.
Change-Id: I41f243633dacb606dbcc3132972f63bbaba174d1
PackParser permits supplying a specific ObjectChecker instance.
Allow this to be passed through ReceivePack, giving the caller
more flexibility to configure the implementation.
Change-Id: I9440dd25588008626222f33bfd697f57c05b439e
Mac OS X and Windows filesystems are generally case insensitive and
will fold 'a' and 'A' to the same directory entry. If the checker is
enforcing safe semantics for these platforms, track all names and
look for duplicates after folding case and normalizing to NFC.
Change-Id: I170b6f649a72d6ef322b7254943d4c604a8d25b9
Reuse the generic logic in ObjectChecker to examine paths.
This required extracting the scanner loop to check for bad
characters within the path name segment.
Change-Id: I02e964d114fb544a0c1657790d5367c3a2b09dff
Most Mac OS X systems use a case insensitive HFS+ volume. Like
Windows ".git" and ".GIT" are the same path and can confuse a Git
program into expecting a repository where one does not exist.
Change-Id: Iec6ce9e6c2872f8b0850cc6aec023fa0fcb05ae4
If Windows rejection is enabled reject special device names like
NUL and PRN, including NUL.txt. This prevents a tree that might
be used on a Windows client from referencing a confusing name.
Change-Id: Ic700ea8fa68724509e0357d4b758a41178c4d70c
Repositories that are frequently checked out on Windows platforms
may need to ensure trees do not contain strange names that cause
problems on those systems. Follow the MSDN guidelines and refuse
to accept a tree containing a special character, or names that end
with " " (space) or "." (dot).
Since Windows filesystems are usually case insensitive, also reject
mixed case versions of the reserved ".git" name.
Change-Id: Ic3042444b1e162c6d01b88c7e6ea39b2a73c4eca
Using .git as a name in a tree is invalid for most Git repositories.
This can confuse clients into thinking there is a submodule or another
repository deeper in the tree, which is incorrect.
Change-Id: I90a1eaf25d45e91557f3f548b69cdcd8f7cddce1
Start pulling out the path segment checking. This will be used
later to support DirCacheCheckout verification of paths, after
folding that logic into this location.
Change-Id: I66eaee5c988eb7d425fb7a708ef6f5419ab77348
The leading '0' is a broken mode that although incorrect in the
Git canonical tree format was created by a couple of libraries
frequently used on a popular Git hosting site. Some projects have
these modes stuck in their ancient history and cannot easily
repair the damage without a full history rewrite. Optionally permit
ObjectChecker to ignore them.
Bug: 307291
Change-Id: Ib921dfd77ce757e89280d1c00328a88430daef35
Catching Exception and rethrowing as Error when the Java7 factory was
not available threw an unexpected error to the caller, but then
confused things by still setting the factory to the default Java
5 version. A second call to FS.detect(Boolean) would succeed.
Do not throw to the caller. Instead always default to the Java5
factory if the Java7 one is not loading.
Change-Id: I6e9edb257b404d213ff08c44560fdb1672a5c80b
Blaming with core.autocrlf set to 'true' - even for freshly checked out
files - showed all lines as being locally modified. For autocrlf = true
the line breaks of the local file will be converted to LF for blaming.
This results in useful diffs and therefor in the desired blame
annotations.
For autocrlf = input no conversion takes place to cope with CRLF line
breaks in the repository, in addition to the usual LF. For autocrlf =
true CRLF line breaks in the repo can't be supported without additional
effort. In that case the whole local file will be blamed as being
locally modified.
Change-Id: If020dcca54d16b2fb79210a070b8480aec82e58e
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
* stable-3.3:
Update scripts to deploy jgit on Maven central
Prepare 3.3.1-SNAPSHOT builds
JGit v3.3.0.201403021825-r
Fix merge/cherry-picking in CRLF mode
Expose the received pack size in ReceivePack
Revert "Add getPackFile to ReceivePack to make PostReceiveHook more usable"
Avoid an NPE after 7b01a53692
Add a launcher for Java 7 tests
Remove obsolete getRepositoryMethod from WorkingTreeIterator
Fix NPE when WorkingTreeIterator does not have a repository set
Add getPackFile to ReceivePack to make PostReceiveHook more usable
Possibility to limit the max pack size on receive-pack
Package httpclient and httpcore in o.e.j.http.apache.feature
Change-Id: I814a150980854bbaabd767f97b062d247af6cb50
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Java spec requires the @Deprecated annotation on any deprecated
field or method. Add the missing annotation to fields and methods
already declared deprecated in the javadoc.
Change-Id: Ic0ef24b43cfd99ac947e771ef5a28e493c304274
This fixes a case where we have CRLF in the repo but
LF in the worktree and are in autocrlf mode.
Change-Id: I0388270c1cf0fd22dfd513bcaa404eb97268d39d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
PostReceiveHooks can make use of this information to, for example,
update a cached size of the Git repository.
Change-Id: I2bf1200959a50531e2155a7609c96035ba45b10d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
usable"
This reverts commit 2670fd427c.
By returning an instance of File from the ReceivePack.getPackFile the
abstraction of the persistence implementation was broken.
Change-Id: I28e3ebf3a659a7cbc94be51bba9e1ad338f2b786
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
While fixing an NPE, I introduced another one in a deprecated isModified
method. It cannot avoid NPE's entirely, which is the reason the method
is deprecated
Change-Id: I5147c1c94621586dd84bd11e6090a954523b6c1c
The method was added for symlink support, but isn't needed anymore.
Since it was added for this release it's like it never existed.
Change-Id: I422cd1dcdfa40b25ba3d6e08b112159dae9a4353
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
It's strange that we have that member since it is not so clear
when it it set or not.
Change-Id: I53903a264f46866d249901a3cd9f9295028aa6bd
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
During a checkout we want to prevent to overwrite unsaved local file
content. Jgit was therefore checking whether the file to overwrite is
dirty or missing and would raise a conflict if this was the case. That
was wrong. It should only check if the file is dirty. It's ok to
"overwrite" a missing/non-existing file.
Change-Id: I63c3a94f663c87f09170fdf8b1b1bf4ed5246fc5
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Some of our Windows users have reported sporadic file system access
problems related to ObjectDirectory(Inserter) file deletion code in
combination with antiviral/firewall tools. For one of these users the
problem was fairly reproducible and changing deletion to RETRY solved
his problem.
Change-Id: I1e4001d5557fca693b7bac401268599467cb0c9e
Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
Having access to the pack file that was created by the ReceivePack
may be useful for post receive hooks. For example, a hook may want
to check the size of the received pack and the created index.
Change-Id: I4d51758e4565d32c9f8892242947eb72644b847d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The maxPackSizeLimit, when set, will reject a pack if it exceeds
that limit.
This feature is intended to provide a mechanism to control disk space
quota on Git repositories.
Change-Id: I83d8db670875c395f8171461b402083323e623a5
CQ: 7896
This move avoids that all consumers of org.eclipse.jgit depend on Apache
httpclient. Also add another feature to make this optional for OSGi
consumers as well.
Change-Id: I5ef5e00c53678b9e1d7cfd54bbca3ff6f1c1c967
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When git-core renames or copies a file and the mode differs the
header shows the mode change first, then the rename or copy data:
diff --git a/COPYING b/LICENSE
old mode 100644
new mode 100755
similarity index 92%
rename from COPYING
rename to LICENSE
index d645695..54863be
--- a/COPYING
+++ b/LICENSE
@@ -56,20 +56,6 @@
JGit relies on this ordering inside of FileHeader. Parsing "new file
mode NNN" after "copy from/to" or "rename from/to" resets the change
type to be ADD, losing the COPIED or RENAMED status and old path.
This fixes a 4 year old bug in Gerrit Code Review that prevents
opening a file for review if the file was copied from another file,
modified in this change, and the mode was updated (e.g. execute
bit was added).
Change-Id: If4c9ecd61ef0ca8e3e1ea857301f7b5c948efb96
[ms: added test case]
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This change implements the http connection abstraction with the help of
org.apache.http.client.HttpClient. The default implementation used by
JGit is still the JDK HttpURLConnection. But now JGit users have the
possibility to switch completely to org.apache.httpclient. The reason
for this is that in certain (e.g. cloud) environments you are forced to
use the org.apache classes.
Change-Id: I0b357f23243ed13a014c79ba179fa327dfe318b2
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Previously all HTTP communication was done with the help of
java.net.HttpUrlConnection. In order to make JGit usable in environments
where the direct usage of such connections is not allowed but where the
environment provides other means to get network connections an
abstraction for connections is introduced. The idea is that new
implementations of this interface will be introduced which will not use
java.net.HttpUrlConnection but use e.g.
org.apache.client.http.HttpClient to provide network connections.
One example: certain cloud infrastructures don't allow that components
in the cloud communicate directly with HttpUrlConnection. Instead they
provide services where a component can ask for a connection (given a
symbolic name for the destination) and where the infrastructure returns
a preconfigured org.apache.http.client.HttpClient. In order to allow
JGit to be running in such environments we need the abstraction
introduced in this commit.
Change-Id: I3b06629f90a118bd284e55bb3f6465fe7d10463d
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This method always returns false and is private so it cannot be
overridden at runtime by a subclass. Drop the method and the branch
that can never be taken.
Change-Id: I4d3edbf469c6739dca191e62ea580bdb534b67a4
These methods do not touch instance members and can avoid the
implicit "this" argument.
Change-Id: I01c30bb22266eed1c9db18bdf9f90c1c1590e3ec
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Also imply remoteBranchName to match current branch name if it wasn't
configured in branch configuration.
Bug: 424812
Change-Id: Id852cedaefb2a537b6aa3c330b9861efad052f11
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
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>
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>
* stable-3.2:
Canonicalize worktree path in BaseRepositoryBuilder if set via config
Add missing @since tags for new public methods in Config
Don't use API exception in RebaseTodoLine
Fix aborting rebase with detached head
Add recursive variant of Config.getNames() methods
Prepare post 3.2.0-m3 builds
JGit v3.2.0.201311130903-m3
Change-Id: Iad6e284e0fe2c7950f156372b334e47ebd82f3f7
Signed-off-by: Matthias Sohn <matthias.sohn@sap.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>
Applying a stash on another commit failed because the merge base for the
cherry-pick of the stashed index state was not corectly set.
Bug: 422684
Change-Id: I9355352b2b9a7abefa3248ca3c17a9301177d0d6
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Otherwise switching to another locale yields wrong results when parsing
date strings in GitDateParser. Since the MockSystemReader explicitly
uses english locale the tests need to specify the locale to be used when
parsing date strings.
Bug: 420772
Change-Id: I313ef6b1e9ef3bfb43d929ce34712ebd21f2cd9c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Empty lines of discarded commit messages were added to the commit
message because they were not commented out properly.
Bug: 422246
Change-Id: I263e8a6b30a3392d8b4f09c0695505068a0a485d
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
The API in org.eclipse.jgit.api does allow to open repositories but it
did not allow to close them. This commit fixes this and allows
API users to close a repository without having to use lower-level
classes.
Bug: 420502
Change-Id: I866225cc8534ae5916113fa24eb1c7513fd4472e
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
DfsPackFile.isIndexLoaded() uses the DfsBlockCache.Ref.get() method
to check if the index loaded. However, using the get() method marks
a hot bit in the cache, which can cause the index to never be unloaded
and seem hotter than it really is. Add a has() method which only
checks if the value is not null and does not update the hot bit.
Change-Id: I7e9ed216f6e273e8f5d79ae573973197654419b4
If during an garbage collection old packfiles are deleted it could
happen that on certain platforms the index file can be deleted but the
packfile can't be deleted (because someone locked the file). This led
to repositories with packfiles without corresponding index files. Those
zombie-packfiles potentially consume a lot of space on disk and it is
never tried to delete them again. Try to avoid this situation by
deleting packfiles first and don't try to delete the other files if we
can't delete the packfile. This gives us the chance to delete the
packfile during next GC.
This commit only improves the situation - there is still the chance for
orphan files during packfile deletion. We don't have an atomic delete
of multiple files .
Change-Id: I0a19ae630186f07d0cc7fe9df246fa1cedeca8f6
This silences some discouraged access warnings issued since
TestRepository uses PackWriter which is in an internal package.
Change-Id: Ic9c4631e237c2fe1996c518328ecc2a9ab5c348b
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
If a commit was marked for edit, reword, squash or fixup, but the
interactive rebase stopped because of a conflict, the step was not done
after conflict resolution. This is done now.
Change-Id: If8e7ccc50469165744f2b8a53d180f9ba0f72330
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When the last step was an edit step, rebase interactive did not finish
after continuing the rebase. Instead, it returned with the status
FAST_FORWARD.
Change-Id: Ib19857474ac089dfeaae665ad5e95c66c21099b0
* changes:
Use absolute paths for file:// URIs in tests
Use getPath() in FileResolverTest
Extract protocol constants to a common class
Move repeat() to utility class for tests
Remove hardcoded target/trash from test cases
Remove dependency on StatusCommandTest
Remove dependency on DiffFormatterReflowTest
Remove unnecessary import of BaseConnection in MessageWriter
With the new RebaseResult.EDIT a client can now distinguish if rebase
stopped due to a conflict or because the commit was marked for edit in
an interactive rebase.
Change-Id: I40f2311cf43ed5f290dcda65a7bd85ba770a85f5
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
The rebase command now supports squash and fixup. Both actions are not
allowed as the first step of the rebase.
In JGit, before any rebase step is performed, the next commit is
already cherry-picked. This commit keeps that behaviour. In case of
squash or fixup a soft reset to the parent is perfomed afterwards.
CQ: 7684
Bug: 396510
Change-Id: I3c4190940b4d7f19860e223d647fc78705e57203
Signed-off-by: Tobias Pfeifer <to.pfeifer@web.de>
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This should prevent class cast problems caused by jgit and egit bundles
wiring to different versions of com.jcraft.jsch.
Bug: 420903
Change-Id: Icabe40209ea07369e2b7eee31952d131aef3fbf1
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Add Operation.PROCESS_STEPS to RebaseCommand to enable starting
interactive rebase explicitly after rebase steps have been configured.
Change-Id: I2d6f0de82010ea6523fbce6fb4501e847bdcdddc
Signed-off-by: Tobias Pfeifer <to.pfeifer@web.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Checking of spaces at the end of the file name caused the
test to fail for Windows only.
Bug: 396662
Change-Id: I47bcccb0fa32ce606276c3f30d454851d115ca11
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
A rebase todo file consists of regular non-comment action lines and
comment lines. In case that a regular action line has been commented out
(i.e. prefixed with a hash '#'), the RebaseTodoLine that is representing
this line should hold the values for commitId and shortMessage even
though it's a comment line. This allows to switch between comment and
non-comment easily even after the file has been persisted and reread.
Change-Id: I56ec2ba08eaf3772e2d74d937dd496209a744d4b
Signed-off-by: Tobias Pfeifer <to.pfeifer@web.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Reading and writing files formatted like the git-rebase-todo files was
hidden in the RebaseCommand. Certain constructs (like leading tabs and
spaces) have not been handled as in native git. Also the upcoming
rebase interactive feature in EGit needs reading/writing these files
independently from a RebaseCommand.
Therefore reading and writing those files has been moved to the
Repository class. RebaseCommand gets smaller because of that and doesn't
have to deal with reading/writing files.
Additional tests for empty todo-list files, or files containing comments
have been added.
Change-Id: I323f3619952fecdf28ddf50139a88e0bea34f5ba
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Also-by: Tobias Pfeifer <to.pfeifer@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This allows subclasses to configure the HTTP connection (for example,
to add headers to the request).
Bug: 400724
Change-Id: I6f9d699e158a7b9d813c8fa8d273992a28994e41
Signed-off-by: Michael Nelson <michael.nelson@tasktop.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Otherwise the MockSystemReader from the test setup is active for other
tests.
Change-Id: I7caf693bd692d06936e29efd4dc4aabb48c1c39b
Signed-off-by: Robin Stocker <robin@nibor.org>
IOException did not add a (String, Throwable) constructor until 1.5.
Instead use the String super constructor and initCause to initialize
the exception.
Fixes bug 418889
Change-Id: Ide735ecfc7d04884981b79b57a4275863ce17006
ServiceMayNotContinueException usually wraps an underlying exception.
Add convenience constructors that take Throwable. In the case a
string is not provided, the message defaults to "internal server error",
since it may be reported to the client.
Change-Id: I15dc20306826c352f69e88afb7ed6927c12b6c1f
Currently, Repository.getAllRefs() and Repository.getTags() silently
ignores an IOException and instead returns an empty map. Repository
is a public API and as such cannot be changed until the next major
revision change. Where possible, update the internal jgit APIs to
use the RefDatabase directly, since it propagates the error.
Change-Id: I4e4537d8bd0fa772f388262684c5c4ca1929dc4c
* stable-3.1:
Prepare post 3.1.0 builds
JGit v3.1.0.201310021548-r
Fix order of commits in rebase todo file header
Prepare post 3.1.0 RC1 builds
JGit v3.1.0.201309270735-rc1
Attempt to fix graph layout when new heads are introduced
Prepare re-signing pgm's ueberjar to avoid SecurityException
Use full branch name when getting ref in BranchTrackingStatus
Change-Id: Ida30175d0c058048cbe4b563aae7f85cd008db29
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Sometime the new commit is no allocated onto a new lane leading to
the commit being drawn on the wrong branch and something that looks
like a merge.
The drawback is that this also changes existing valid graphs.
Bug: 368927
Change-Id: Ic8a8247c8a53be802c1be83850ed766b902ca646
If we encounter an I/O error while writing an archive (for example due
to the reader of an HTTP stream closing the connection), the result is
an archive with unclosed entries, causing
TarArchiveOutputStream.finish() to throw IOException("This archives
contains unclosed entries"), hiding the IOException that caused the
early termination.
The unclosed entries are fine: the same exception that occured in the
first place will probably prevent closing the entries before finishing
this partial archive that should be discarded anyway.
It would be nicer to call TarArchiveOutputStream.finish and leave the
underlying OutputStream unclosed --- all callers close it already ---
but that would be a more invasive change so we hold off for now.
Change-Id: I328ced19aa8a1888e5353cdbb6106a85fd72d5d7
Signed-off-by: Jonathan Nieder <jrn@google.com>
In case there is both a tag and branch called "foo", the tag is returned
if calling getRef with the short name. By using refs/heads/foo, the
branch is returned.
Bug: 417158
Change-Id: I86b4f83955586bb24774fd621f5012499cf67909
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
If `git gc` creates a new pack with the same file name, the
pack checksum may not match that in the .bitmap. Fix the PackFile
implementaion to silently ignore invalid bitmap indexes.
Fixes Issue https://code.google.com/p/gerrit/issues/detail?id=2131
Change-Id: I378673c00de32385ba90f4b639cb812f9574a216
Previously, the DfsPackCompactor exited without pruning the existing
packs, when no new packs were created.
Change-Id: I5e3b6f8c789706c7a982e6ae93cf7c3d4346797c
In C Git 1.8.2, "git reset" now also works on an unborn branch (no HEAD
yet) if no explicit ref was specified. In that case, it is treated as a
reset to an empty tree.
This can be useful for callers because "unborn branch" no longer has to
be special-cased to "git rm --cached".
Bug: 414870
Change-Id: Ied750116f767518ae4d48823cf00752b049a8477
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
OpenJDK 7 does not benefit from using an inflate stride on the input
array. The implementation of java.util.zip.Inflater supplies the
entire input byte[] to libz, with no regards for the bounds supplied.
Slicing at 512 byte increments in DfsBlock no longer has any benefit.
In OpenJDK 6 the native portion of Inflater used GetByteArrayRegion
to obtain a copy of the input buffer for libz. In this use case
supplying a small stride made sense, it avoided allocating space
for and copying data past the end of the object's compressed stream.
In OpenJDK 7 the native code uses GetPrimitiveArrayCritical,
which tries to avoid copying by freezing Java garbage collection
and accessing the byte[] contents in place. On OpenJDK 7 derived
JVMs it is likely more efficient to supply the entire DfsBlock.
Since OpenJDK 5 and 6 are deprecated and replaced by OpenJDK 7
it is reasonable to suggest any consumers running JGit with DFS
support use an OpenJDK 7 derived JVM. However, JGit still targets
local filesystem support on Java 5, so it is still not reasonble to
apply this same simplification to the internal.storage.file package.
See: JDK-6751338 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6751338)
Change-Id: Ib248b6d383da5c8aa887d9c355a0df6f3e2247a5
The dash signing plugin has been retired hence we need to update our
build to use the CBI jarsigner plugin for signing build results.
Pack test classes to enable signing them.
Also re-enable pack200 for bundle org.eclipse.jgit.
WORKAROUND: there is no easy way to run tests with maven-surefire-plugin
from signed test-jar so for a quick workaround we will have to add a
build step on Hudson so that we can run tests before signing:
- first step will do "clean, verify" to compile and run tests
- second step will do "install, deploy" with profile "eclipse-sign" and
use -DskipTests=true to skip tests since they would hit a
SecurityException when unsigned test classes are in same package as
signed classes under test
- third step will do "clean, install, deploy" on packaging reactor to
build features and p2 repository with profile "eclipse-sign" to sign
and pack200 all bundles.
TODO: Tycho doesn't suport picking up pack200 artifacts via
pomDependencies hence we need to find a way to copy them manually and
use tycho-extra's tycho-p2-extras-plugin:publish-features-and-bundles
to generate the missing p2 metadata.
Change-Id: Iec2c5ab3027a3e3f9ecc0d2f99193385177d9025
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
There was a chance that jgit deletes symbolic links which point to the
folder on top of the working tree. Make sure not to touch these
resources.
Thanks to Cedric Darloy who reported this bug on
http://www.eclipse.org/forums/index.php/m/776910/#msg_776910 and to
Ondrej Vrabec who reported bug 412489.
Bug: 412489
Change-Id: I81735ba0394ef6794e9b2b8bdd8bd7e8b9c6460f
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Robin Stocker <robin@nibor.org>
* It didn't check the first character in the pattern due to a off-by-one
error. Spotted by James Roper.
* It returned true even when pattern was longer than current path, e.g.
it returned that ".txt" is suffix of "txt".
Bug: 411999
Change-Id: I9fbcd68a11fb57cc49956b70c387a47271a0424f
Signed-off-by: Robin Stocker <robin@nibor.org>
parentFile becomes null when f is relative path, such as ".".
This patch avoids NullPointerException in such case.
Change-Id: I4752674b1daab6eedd7c3650c7749462810eaffd
Signed-off-by: Hiroshi Tomita <tomykaira@gmail.com>
Without update, index is wrongly detected to be dirty
when picking the second commit.
Change-Id: Idf47ecb33e8bd38340d760806d629f67be92d2d5
Signed-off-by: Hiroshi Tomita <tomykaira@gmail.com>
Bug: 411963
The original code was able to process only one WWW-Authenticate
header in an HTTP response, and if this header was not one of
two expected, authentication failed regardless of that there
could be other headers in the response.
All WWW-Authenticate headers in an HTTP response have to be
browsed to find one of supported, i.e. Basic or Digest.
By that if both are present, the Digest one should be used
as more preferable.
Bug: 357719
Change-Id: Icf601a41fec63f7d40308f3c85aaa4f71a7c095b
Signed-off-by: Alex Rukhlin <arukhlin@microsoft.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
It's supported by C Git and can be useful.
Bug: 413388
Change-Id: I12c6c10e791cc09ee271d89eb8b8d32f53e385db
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Change-Id: I9754e2124c0fe6ad2dbde5597c3ed10f1c3efef5
Signed-off-by: Lars Vogel <Lars.Vogel@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
With reference hiding, it is possible for a repository to appear
empty when all refs are hidden. This causes capabilities to not be
advertised either, since they are published with the first reference,
breaking fetch by SHA1 support.
Always advertise the capabilites by publishing the symbolic capabilities
reference when the repository has no references to advertise (similar to
the receive service).
Change-Id: I8060e430ee03571dc51239e702864c85e888505c
UploadPack can be invoked with no capabilities selected by the
client if the client is an ancient version of Git that nobody in
their right mind should still be using. Or if the client is very
broken and does not want to use any of the newer features added to
the protocol since its inception.
Change-Id: I3baa6f90e6a41a37a8eab8449a3cc41f4efcb91a
The NullProgressMonitor does not report progress anywhere. Inform the
server not to send progress by enabling the no-progress capability.
Change-Id: Id18dbc754c814d1a5534a284c947030bf201c569
Instead of RevObject list, this allows a custom request validator to be called
on SHA-1's corresponding to objects that may not exist in repository storage
Change-Id: I19bb667beff0d0c144150a61d7a1dc6c9703be7f
Signed-off-by: Greg Hill <greghill@google.com>
This is useful if Git.status() is a long running command.
Change-Id: I6bdbf347a688043d549c1f091fb4a264a6c7024e
Signed-off-by: Christian Trutz <christian.trutz@gmail.com>
Signed-off-by: Robin Stocker <robin@nibor.org>
Can be used for listing remote refs for a repository on the file system
without having a local repository.
Bug: 413400
Change-Id: I397f5092c5eafb62236e9f9e74d9183f56903cc6
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Setting the walk and other fields to null will result in NPEs when the
user e.g. calls fetch on the connection, but at least the advertised
refs can be read like that without having a local repository.
Bug: 413389
Change-Id: I39c8363e81a1c7e6cb3412ba88542ead669e69ed
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Change-Id: I1077dbb1f10c7cc687c0d1b8a8e8f763ca96977c
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Allow filtering of the status. Only files which match given paths are
inspected and only their state is reported.
Change-Id: I3c4b1b46bf297cd4ebdb4997cfa14c8752a36411
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
It had a typo (commited) and was not in the style of the others.
Change-Id: Ia1be1c70b13bb2f3da80c8e8239c5f254070fe60
Signed-off-by: Robin Stocker <robin@nibor.org>
DirCacheCheckout had a bug when the parentdirectory of a worktree was a
symlink. DirCacheCheckout was deleting those symlinks under certain
conditions. This was fixed in I81735ba0394ef6794e9b2b8bdd8bd7e8b9c6460f
without a test because previously it was hard to setup tests containing
symlinks.
BUG: 412489
Change-Id: I2513166af519d6fc01d1eae3976ad6cff6f98530
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
There was a chance that jgit deletes symbolic links which point to the
folder on top of the working tree. Make sure not to touch these
resources.
Thanks to Cedric Darloy who reported this bug on
http://www.eclipse.org/forums/index.php/m/776910/#msg_776910 and to
Ondrej Vrabec who reported bug 412489.
Bug: 412489
Change-Id: I81735ba0394ef6794e9b2b8bdd8bd7e8b9c6460f
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Robin Stocker <robin@nibor.org>
* It didn't check the first character in the pattern due to a off-by-one
error. Spotted by James Roper.
* It returned true even when pattern was longer than current path, e.g.
it returned that ".txt" is suffix of "txt".
Bug: 411999
Change-Id: I9fbcd68a11fb57cc49956b70c387a47271a0424f
Signed-off-by: Robin Stocker <robin@nibor.org>
parentFile becomes null when f is relative path, such as ".".
This patch avoids NullPointerException in such case.
Change-Id: I4752674b1daab6eedd7c3650c7749462810eaffd
Signed-off-by: Hiroshi Tomita <tomykaira@gmail.com>
Make the existing concrete implementations public as well so custom
implementations may delegate to them where appropriate. Treat all custom
implementations as providing allow-tip-sha1 in want.
Change-Id: If386fe25c0d3b4551a97c16a22350714453b03e9
Associate each RequestPolicy with an implementation of a
RequestValidator interface that contains the validation logic. The
checkWants method is only called if there are wants that were not
advertised, since clients may always request any advertised want
according to the git protocol. Calling the method only once at the
end of parsing the want list also means policy implementations can be
stateful, unlike the previous switch statement inside a loop.
For the special handling of unidirectional pipes, simply check
isBiDirectional() and delegate to other implementations if necessary.
Change-Id: I52a174999ac3a5aca46d3469cb0b81edd1710580
C git 1.8.2 supports setting the equivalent of RequestPolicy.TIP with
uploadpack.allowtipsha1. Parse this into TransportConfig and use it
from UploadPack. An explicitly set RequestPolicy overrides the config,
and the policy may still be upgraded on a unidirectional connection to
avoid races.
Defer figuring out the effective RequestPolicy to later in the
process. This is a minor semantic change to fix a bug: previously,
calling setRequestPolicy(ADVERTISED) _after_ calling
setBiDirectionalPipe(true) would have reintroduced the race condition
otherwise fixed by 01888db892.
Change-Id: I264e028a76574434cecb34904d9f5944b290df78
This protocol capability, new in C git 1.8.2, corresponds to
RequestPolicy.TIP, so advertise it if that request policy was set.
Change-Id: I0d52af8a7747e951a87f060a5124f822ce1b2b26
Users of UploadPack may set a custom RefFilter or AdvertisedRefsHook
that limits which refs are advertised, but clients may learn of a
SHA-1 that the server should have as a ref tip through some
alternative means. Support serving such objects from the server side
with a new RequestPolicy.
As with ADVERTISED, we need a special relaxed RequestPolicy to allow
commits reachable from the set of valid tips for unidirectional
connections.
Change-Id: I0d0cc4f8ee04d265e5be8221b9384afb1b374315
Previously it took 1200ms to create a reverse index (sorted by offset).
Using a simple bucket sort algorithm, that time is reduced to 450ms.
The bucket index into the offset array is kept, in order to decrease
the binary search window.
Don't keep a copy of the offsets. Instead, use nth position
to lookup the offset in the PackIndex.
Change-Id: If51ab76752622e04a4430d9a14db95ad02f5329d
Without update, index is wrongly detected to be dirty
when picking the second commit.
Change-Id: Idf47ecb33e8bd38340d760806d629f67be92d2d5
Signed-off-by: Hiroshi Tomita <tomykaira@gmail.com>
Bug: 411963
Currently, the offset can only be retrieved by ObjectId or iterating all
of the entries. Add a method to lookup the offset by position in the
index sorted by SHA1.
Change-Id: I45e9ac8b752d1dab47b202753a1dcca7122b958e
The original code was able to process only one WWW-Authenticate
header in an HTTP response, and if this header was not one of
two expected, authentication failed regardless of that there
could be other headers in the response.
All WWW-Authenticate headers in an HTTP response have to be
browsed to find one of supported, i.e. Basic or Digest.
By that if both are present, the Digest one should be used
as more preferable.
Bug: 357719
Change-Id: Icf601a41fec63f7d40308f3c85aaa4f71a7c095b
Signed-off-by: Alex Rukhlin <arukhlin@microsoft.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
See change I08bed4275af9ec52aa4d7054067ac82f6a3c9781, where fixing such
warning lead to complaints.
If fixing is not wanted, disable it instead.
Change-Id: If31d4028fa1c6377a11e83ed5688b45701cec68b
Introduce a setFilename() method for ArchiveCommand so callers can
specify the intended filename of the produced archive. If the
filename ends with .tar, the format will default to tar; if .zip, zip;
if .tar.gz, gzip-compressed tar; and so on.
This doesn't affect "jgit archive" because it doesn't support the
--output=<file> option yet. A later patch might do that.
Change-Id: Ic0236a70f7aa7f2271c3ef11083b21ee986b4df5
Document archive formats, the archive format interface, and the
parameters of the GitAPIException constructors. Noticed by eclipse.
Reported-by: Dani Megert <Daniel_Megert@ch.ibm.com>
Change-Id: I22b5f9d4c0358bbe867c1906feec7c279e214273
* stable-3.0:
Prepare post 3.0.0-rc2 builds
JGit v3.0.0.201305281830-rc2
Support refspecs with wildcard in middle (not only at end)
Fix multiple bugs in RawSubStringPattern used by MessageRevFilter
Handle short branch/tag name for setBranch in CloneCommand
Add missing Bundle-Localization header
Apply tree filter marks when pairing DiffEntry for renames
Improve feature names to become understandable by end users
Update kepler orbit version to R20130517111416
Fix BatchRefUpdate progress-monitoring so it doesn't count twice
Fix AnyObjectId's generic type declaration of Comparable
Fix DiffFormatter NPEs for DiffEntry without content change
Fix CommitCommand not to destroy repo
Fix the parameters to an exception
Prepare post 3.0.0 M7 builds
JGit v3.0.0.201305080800-m7
Change-Id: Ia8441c9796f01497e0d90e672c0aaf60520a0098
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The following refspec, which can be used to fetch GitHub pull requests,
is supported by C Git but was not yet by JGit:
+refs/pull/*/head:refs/remotes/origin/pr/*
The reason is that the wildcard in the source is in the middle.
This change also includes more validation (e.g. "refs//heads" is not
valid) and test cases.
Bug: 405099
Change-Id: I9bcef7785a0762ed0a98ca95a0bdf8879d5702aa
* Match at end of input was not handled correctly.
* When more than one character matched but not all, the next character
was not considered as a match start (e.g. pattern "abab" didn't match
input "abaabab").
Bug: 409144
Change-Id: Ia44682c618bfbb927f5567c194227421d222a160
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Before, it was not clear from the documentation what kind of branch name
was accepted. Users specifying "branch" (instead of "refs/heads/branch")
got no error message and ended up with a repository without HEAD and no
checkout.
With this, CloneCommand now tries "$branch", then "refs/heads/$branch"
and then "refs/tags/$branch". C Git only does the last two, but for
compatibility we should still allow "refs/heads/branch".
Bug: 390994
Change-Id: I4be13144f2a21a6583e0942f0c7c40da32f2247a
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Make call() release all private resources so instead of using a
pattern like
ArchiveCommand cmd = git.archive();
try {
cmd.setTree(tree)
. ...
.call();
} finally {
cmd.release();
}
callers can just use git.archive().setTree(tree)....call() directly.
This involves pushing more work out of parameter setters and into
call() so the ObjectReader is not allocated and potentially leaked
before then.
Change-Id: I699f703c6302696e1cc276d7ab8ee597d82f2c5d
Allow use of ArchiveCommand without depending on the jgit command-line
tools.
To avoid complicating the process of installing and upgrading JGit,
this does not add a dependency by the org.eclipse.jgit bundle on
commons-compress. Instead, the caller is responsible for registering
any formats they want to use by calling ArchiveCommand.registerFormat.
This patch puts functionality that requires an archiver into a
separate org.eclipse.jgit.archive bundle for people who want it. One
can use it by calling ArchiveCommand.registerFormat directly to
register its formats or by relying on OSGi class loading to load
org.eclipse.jgit.archive.FormatActivator, which takes care of
registration automatically.
Once the appropriate formats are registered, you can make a tar or zip
from a git tree object as follows:
ArchiveCommand cmd = git.archive();
try {
cmd.setTree(tree).setFormat(fmt).setOutputStream(out).call();
} finally {
cmd.release();
}
Change-Id: I418e7e7d76422dc6f010d0b3b624d7bec3b20c6e
When using a RenameDetector to generate new DiffEntries after using
DiffEntry.scan, the treeFilterMarks of the original entries were lost.
Now it combines the marks from src and dst.
See EGit bug 335082 where this is used.
Change-Id: I72b34b10ca12e3a6bd10ce44f4fa05b193fc52cc
The stream should not throw IllegalStateException if it is off.
Flush the stream after the hook runs, in case any messages need
to be sent ahead of the pack.
Change-Id: I21c7a0258ab1308406d226293fa0e7da69b4f57b
Before transmitting to the client a hook may want to send along
a text message ahead of the pack, such as a "message of the day".
Enable this usage by mirroring the message sending API from
ReceivePack on the UploadPack instance, using the side band.
Change-Id: I31cd254a4ddb816641397a3e9c2c20212471c37f
I was seeing output like this while running The BFG:
Updating references: 200% (374/187)
...issue sneaked in with 5cf53fda I think.
The update call is also moved to the end of the loop, as update() is
only supposed to be called after work has been done ("Denote that some
work units have been completed").
Change-Id: I1620fa75be16dc80df44745d0e123ea512762e31
Signed-off-by: Robin Stocker <robin@nibor.org>
If you look at any implementation of Comparable in the JDK, you'll see
that the type parameter for Comparable is supposed to be the type of
the implementing class:
http://docs.oracle.com/javase/6/docs/api/java/lang/Comparable.html
The current type signature of Comparable<Object> is pretty awful, at the
very least because you can not, in fact, successfully compare
AnyObjectId with any random subclass of Object. It also causes problems
with type-inference and the scala.math.Ordering trait in Scala.
In order to compile, this change *does* require removing the
AnyObjectId.ompareTo(Object) method - which actually only ever cast
to AnyObjectId in any case. Nothing in the JGit test suite requires this
method, but it might constitute a breaking API change, so it would be
best if it can be added in time for JGit 3.0.
Change-Id: I3b549a5519ccd6785f98e444da76d2363bcbe41a
DiffEntry.getOldId() returns null for a diff without an index line (e.g.
only mode changed, rename without content change).
Bug: 407743
Change-Id: I42eac87421f2a53c985af260a253338f578492bc
There was a severe bug in CommitCommand which could corrupt
repos. When merging an annotated tag the JGit MergeCommand writes
correctly the ID of the tag (and not the id of the commit the tag was
pointing to) into MERGE_HEAD. Native git does the same. But
CommitCommand was reading this file and trusting blindly that it will
contain only IDs of commits. Then the CommitCommand created a
commit which has as parent a non-commit object (the tag object). That's
so corrupt that even native git gives up when you call "git log" in
such a repo.
To reproduce that with EGit simply right-click on a tag in the
Repository View and select Merge. The result was a corrupt repo!
Bug: 336291
Change-Id: I24cd5de19ce6ca7b68b4052c9e73dcc6d207b57c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
A parenthesis was in the wrong place passing arguments to the wrong
format call. Also fix formatting of enclosing switch statement.
Change-Id: I4cb9642f08b58c39033c3a81dab4bd56bebf4fd2
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The comment about legacy Tag and Object types no longer applies,
though prior to Idb273d5a92849b42935ac14eed73b796b80aad50 the field
was still being used by RewriteTreeFilter.
Change-Id: I9ee5da8f8a3b61c9cf543817c03117ee0609dd8f
The various rename detection options are an inherent part of the
filter, similar to the path being followed.
This fixes a potential NPE when a RevWalk with a FollowFilter is
created without a Repository, since the old code path tried to get
the DiffConfig from the RevWalk's possibly-missing repository.
Change-Id: Idb273d5a92849b42935ac14eed73b796b80aad50
The most important difference is that in Java7 we have symbolic links
and for most operations in the work tree we want to operate on the link
itself rather than the link target, which the old File methods generally
do.
We also add support for the hidden attribute, which only makes sense
on Windows and exists, just since there are claims that Files.exists
is faster the File.exists.
A new bundle is only activated when run with a Java7 execution
environment. It is implemented as a fragment.
Tycho currently has no way to conditionally include optional features
based on the java version used to run the build, this means with this
change the jgit packaging build always needs to be run using java 7.
Change-Id: I3d6580d6fa7b22f60d7e54ab236898ed44954ffd
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When either --tags or a tag ref is explicitly specified on fetch, C Git
updates existing local tags if they are different.
Before this change, JGit returned REJECTED in such a case. Now it
updates it and returns FORCED.
Example:
% mkdir a
% cd a
% git init -q
% touch test.txt
% git add test.txt
% git commit -q -m 'Initial'
% git tag v1
% cd ..
% git clone -q a b
% cd a
% echo Test > test.txt
% git commit -q -a -m 'Second'
% git tag -f v1
Updated tag 'v1' (was bc85c08)
% cd ../b
% git fetch --tags
- [tag update] v1 -> v1
Bug: 388095
Change-Id: I5d5494c2ad1a2cdb8e9e614d3de445289734edfe