Expose ReceiveCommand version of TrackingRefUpdate
If the caller uses a BatchRefUpdate to execute these (e.g. fetch)
there may be more detailed status information inside of the command
that was used to execute it. Allow the caller to obtain that status
data from the ReceiveCommand version of the TrackingRefUpdate.
* changes:
diff: Optimize single line edits
blame: Reduce running time ~4.5% by skipping common subtrees
blame: Micro optimize blob lookup in tree
blame: Automatically increase commit abbreviation length
Blame correctly in the presence of conflicting merges
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.
blame: Reduce running time ~4.5% by skipping common subtrees
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
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().
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.
Konrad Kügler [Sun, 13 Apr 2014 17:21:06 +0000 (19:21 +0200)]
Blame correctly in the presence of conflicting merges
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.
Matthias Sohn [Wed, 26 Mar 2014 22:16:36 +0000 (23:16 +0100)]
Ensure that stored credentials aren't reset too early
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>
Jonathan Nieder [Fri, 11 Apr 2014 21:01:56 +0000 (14:01 -0700)]
Make ArchiveFormats final and implement equals()
This should make it easier to modify ArchiveCommand to allow an
archive format to be registered twice while still noticing if
different callers try to register different implementations for
the same format.
Change-Id: I32261bc8dc1877a853b49e0da0a6e78921791812 Signed-off-by: Jonathan Nieder <jrn@google.com>
Sven Selberg [Mon, 24 Mar 2014 17:05:32 +0000 (18:05 +0100)]
Added TestCase for 7d5e1f Fixed RevWalk.isMergedInto()
Change-Id: Id9a641dd67c4182bb3a0dc83a6864fee43e7653f Signed-off-by: Gustaf Lundh <gustaf.lundh@sonymobile.com> Signed-off-by: Sven Selberg <sven.selberg@sonymobile.com>
Robin Rosenberg [Sun, 30 Mar 2014 09:00:36 +0000 (11:00 +0200)]
Fix ValidRefNameTest on Windows
There are certain ref names which native git can be create only on
non-windows systems (e.g. "refs/tags/>"). On Windows systems we can't
persist this refs because the ref names are not valid file names. Our
tests in ValidRefNameTest assumed that these are valid refs on all
systems. This broke the tests on Windows.
Robin Rosenberg [Sat, 29 Mar 2014 20:59:26 +0000 (21:59 +0100)]
Fix FileTreeIteratorTest#testIsModifiedFileSmudged() on Windows
This would be a problem for any OS where Java lets the subscond
part through to the File API. The fix is to force the timetamp
of the index rather than trusting it to just happen to be right.
Bug: 430765
Change-Id: Id6b3ba003f58427a3ffaacd224649e2d6c93566b Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.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.
Make jgit.java6 and jgit.java7 activation based on ranges so modules in
jgit.java6 are enabled for Java 1.6+ and modules in jgit.java7 are
enabled for Java 1.7+. This enables full compiles on Java 8 and also
removes the need to list org.eclipse.jgit.console in both profiles.
Change-Id: Iabfcff18737ff435ba8d5e8efc7a581abc9a46ce Signed-off-by: Alexander Kurtakov <akurtako@redhat.com>
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/"
Dave Borowitz [Wed, 26 Mar 2014 01:34:54 +0000 (18:34 -0700)]
Fix NameRevCommand when repo has no annotated tags
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.
Matthias Sohn [Tue, 25 Mar 2014 10:03:56 +0000 (11:03 +0100)]
Merge branch 'stable-3.3'
* 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.
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>
Matthias Sohn [Sat, 15 Mar 2014 09:49:22 +0000 (10:49 +0100)]
Retry to call credentials provider if http authentication failed
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.
Ensure that ssh authentication is retried only in JGit
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.
Shawn Pearce [Thu, 13 Mar 2014 19:45:57 +0000 (12:45 -0700)]
Fix StackOverflowError in RevCommit.carryFlags on deep side graphs
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.
Shawn Pearce [Thu, 13 Mar 2014 00:13:10 +0000 (17:13 -0700)]
Display progress while checking connectivity on push
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.
* 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
Shawn Pearce [Wed, 12 Mar 2014 23:53:26 +0000 (16:53 -0700)]
Correct fetch to use fetch.fsckObjects and transfer.fsckObjects
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.
Shawn Pearce [Wed, 12 Mar 2014 23:36:07 +0000 (16:36 -0700)]
Allow ReceivePack callers to configure their own ObjectChecker
PackParser permits supplying a specific ObjectChecker instance.
Allow this to be passed through ReceivePack, giving the caller
more flexibility to configure the implementation.
Shawn Pearce [Wed, 12 Mar 2014 20:59:29 +0000 (13:59 -0700)]
Check for duplicate names after folding case in ObjectChecker
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.
Shawn Pearce [Wed, 12 Mar 2014 19:01:56 +0000 (12:01 -0700)]
Change DirCacheCheckout to verify path using ObjectChecker
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.
Shawn Pearce [Wed, 12 Mar 2014 19:38:13 +0000 (12:38 -0700)]
Reject mixed case .git on Mac OS in ObjectChecker
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.
Shawn Pearce [Wed, 12 Mar 2014 05:49:36 +0000 (22:49 -0700)]
Reject special Windows device names in ObjectChecker
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.
Shawn Pearce [Wed, 12 Mar 2014 04:19:23 +0000 (21:19 -0700)]
Allow an ObjectChecker to reject special characters for Windows
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.
Shawn Pearce [Wed, 12 Mar 2014 03:12:07 +0000 (20:12 -0700)]
Reject '.git' as a tree name in ObjectChecker
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.
Shawn Pearce [Wed, 12 Mar 2014 00:42:01 +0000 (17:42 -0700)]
Extract path segment check function in ObjectChecker
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.
Shawn Pearce [Wed, 12 Mar 2014 00:19:37 +0000 (17:19 -0700)]
Permit ObjectChecker to optionally accept leading '0' in trees
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.
Rename test class so it is also executed during maven test phase
One specific test was executed when running tests from inside eclipse
(e.g. by using one of our checked in launch configurations). But when
running tests from maven this test was not executed. Maven (the surefire
plugin) looks for Tests only in java files which are named like
"Test*.java", "*Test.java" or "*TestCase.java". Tests in files named
"*Tests.java" are not found.
Shawn Pearce [Tue, 11 Mar 2014 21:57:27 +0000 (14:57 -0700)]
Cleanup catch Exception when making Java7FSFactory
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.
Matthias Sohn [Wed, 5 Mar 2014 07:46:11 +0000 (08:46 +0100)]
Update com.jcraft.jsch to 0.1.50 also in pom dependencies
We updated the target platforms in 3.3 following the version shipped
by the release train but missed to update it in pom dependencies.
This wasn't harmful as there were no API changes between 0.1.46 and
0.1.50.
Change-Id: Ie8ac2ea447fa93d6643b9817f58767ab7f0b1aa4 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Konrad Kügler [Sun, 12 Jan 2014 12:39:18 +0000 (13:39 +0100)]
Take core.autocrlf into account for blame annotations
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>
Matthias Sohn [Wed, 5 Mar 2014 07:46:11 +0000 (08:46 +0100)]
Update com.jcraft.jsch to 0.1.50 also in pom dependencies
We updated the target platforms in 3.3 following the version shipped
by the release train but missed to update it in pom dependencies.
This wasn't harmful as there were no API changes between 0.1.46 and
0.1.50.
Change-Id: Ie8ac2ea447fa93d6643b9817f58767ab7f0b1aa4 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Matthias Sohn [Wed, 5 Mar 2014 01:02:03 +0000 (02:02 +0100)]
Merge branch 'stable-3.3'
* 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 7b01a5369210
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>
Shawn Pearce [Mon, 3 Mar 2014 18:37:06 +0000 (10:37 -0800)]
Add missing @Deprecated to deprecated fields and methods
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.
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
Don't raise checkout conflict for file missing in working tree
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>
projects / jgit.git / log