Roberto Tyley [Wed, 21 May 2014 11:36:52 +0000 (12:36 +0100)]
Fix reading past FileTreeIterator EOF in FileTreeIteratorJava7Test
Stepping past the '.git' entry with `fti.next(1)` is unnecessary and in
fact a bug, as the subsequent access to FileTreeIterator is past it's
end-of-file - it has only 1 valid entry ('link').
This bug is only visibly exposed in certain environments depending on the
(unguaranteed) return order of `java.io.File.listFiles()`. On my box
FileTreeIteratorJava7Test would fail consistently for these 3 tests:
testSymlinkActuallyModified(org.eclipse.jgit.treewalk.FileTreeIteratorJava7Test) Time elapsed: 0.063 sec <<< ERROR!
org.eclipse.jgit.api.errors.JGitInternalException: /home/roberto/development/jgit/org.eclipse.jgit.java7.test/target/jgit_test_9202429389985749040_tmp
/tmp_807992722429349842/.git (Is a directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:146)
at org.eclipse.jgit.treewalk.FileTreeIterator$FileEntry.openInputStream(FileTreeIterator.java:210)
at org.eclipse.jgit.treewalk.WorkingTreeIterator.readContentAsNormalizedString(WorkingTreeIterator.java:984)
at org.eclipse.jgit.treewalk.WorkingTreeIterator.contentCheck(WorkingTreeIterator.java:924)
at org.eclipse.jgit.treewalk.WorkingTreeIterator.isModified(WorkingTreeIterator.java:860)
at org.eclipse.jgit.treewalk.WorkingTreeIterator.isModified(WorkingTreeIterator.java:815)
at org.eclipse.jgit.treewalk.FileTreeIteratorJava7Test.testSymlinkActuallyModified(FileTreeIteratorJava7Test.java:198)
Theses tests are all working with a small repo that has just two entries:
'.git' and 'link' (a symbolic link that's being tested on). `listFiles()`
is called by FileTreeIterator to get a preliminary list of FileEntry
objects:
... where a count of valid entries is made (`entryCnt`), the 'invalid'
entries (like'.git') being left in the hinterland of the `entries` array.
The rearrangement in the entries array for our tests looks like this:
In both cases, `entryCnt` is set to 1, meaning that the _valid_ portion of
the iterator is the same (ie ['link']), but that the portion after EOF,
which we reach by calling `fti.next(1)`, is _different_ depending on your
environment. The entry used by the iterator at that point will be either
'link' (if you're lucky) or '.git', which will blow up the test.
Note that somewhat ironically, the 'self-check' assertions don't catch
this bug, as 'path' data is only parsed _before_ EOF - so
`fti.getEntryPathString()` returns the string "link" (and the assertion
passes) regardless of whether you're about to read the '.git' entry or not.
Performing a TreeWalk over 2 trees to identify and skip unmodified
subtrees to pass all blame onto an ancestor appears to be a micro
optimization that works for a very limited number of files. In the
general case the 2 tree walk is slowing down blame more than it helps
to speed it up.
I keep coming up with files in multiple repositories where 6de128 is
making things worse, not better, and only one example where it
actually improved performance, render_view_impl.cc in chromium
as described in the commit message.
Konrad Kügler [Fri, 16 May 2014 16:42:44 +0000 (18:42 +0200)]
Cherry-Pick: Support --mainline to pick merges
By specifying a mainline parent, a merge is cherry picked as if this
parent was its only parent. If no mainline parent is given, cherry
picking merges is not allowed, as before.
Change-Id: I391cb73bf8f49e2df61428c17b40fae8c86a8b76 Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Robin Rosenberg [Sun, 30 Mar 2014 20:04:53 +0000 (22:04 +0200)]
Fix a number of failing conflict situations
Adds further tests where the working tree is dirty (differs from
index) and where we have staged but uncommitted changes.
Fixed the test case 9 for file/directory conflicts.
Bug: 428819
Change-Id: Ie44a288b052abe936ebb74272d0fefef3b218a7a Signed-off-by: Axel Richard <axel.richard@obeo.fr> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Konrad Kügler [Fri, 16 May 2014 07:01:23 +0000 (09:01 +0200)]
Rebase: Write an empty "quiet" file to make C Git happy
C git tries to read this file from the rebase state directory and
complains about it not being there for rebases started by JGit. An empty
'quiet' file represents the (verbose) default.
Change-Id: I1844ccbf8d35442d7a8918b57b67eb9b9efd6352 Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Shaul Zorea [Wed, 7 May 2014 15:50:04 +0000 (18:50 +0300)]
Archive: Add the ability to select one or more paths.
Previously, it was only possible to archive the entire repository.
This patch introduces the ability to select specific files and
directories to archive.
Archiving the entire repository remains the default behaviour.
In two places we threw an IOException and the message was built using
JGitText.couldNotWriteFile. We specified 2 parameters, but this pattern
expects only one parameter. In both places we tried to rename a file,
that's why we wanted two parameters (src and target) for the exception
text.
I changed it to use JGitText.renameFileFailed which accepts two
parameters and fits better.
Change-Id: Ib8c2cf78f2b26ca2b97754fe91fdb20b30392415 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Tomasz Zarna [Sun, 11 May 2014 19:14:30 +0000 (21:14 +0200)]
Fix javadoc errors caused by missing tags for declared exceptions
Change-Id: I587aae0ad217ed092f061682ffa66c724f221096 Signed-off-by: Tomasz Zarna <tomasz.zarna@tasktop.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Matthias Sohn [Wed, 7 May 2014 06:50:33 +0000 (08:50 +0200)]
Fix manifests of source bundles
- don't mark them as singleton to allow coexistence of multiple versions
in the same installation
- add missing version qualifier to Eclipse-SourceBundle header
see
https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10524.html
Change-Id: Ie4e028038f5a1d3e18b0be06c3d2ea82e7f9068d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Dave Borowitz [Tue, 6 May 2014 18:05:14 +0000 (14:05 -0400)]
Merge changes I9ba0e70f,I1f38e055,Idb55a303
* changes:
Do not rewrite parents in RevWalkTextBuiltins
RevWalk: Allow disabling parent rewriting
RevWalkTextBuiltin: Add -n to limit number of commits returned
Dave Borowitz [Mon, 5 May 2014 22:21:16 +0000 (15:21 -0700)]
Do not rewrite parents in RevWalkTextBuiltins
Default behavior of C git is to skip parent rewriting unless
particular history simplification or --parents flags are passed. Since
JGit has no such flags, JGit should not rewrite parents.
Dave Borowitz [Mon, 5 May 2014 22:15:13 +0000 (15:15 -0700)]
RevWalk: Allow disabling parent rewriting
Previously, setting any TreeFilter on a RevWalk triggered parent
rewriting, which in the current StartGenerator implementation ends up
buffering the entire commit history in memory. Aside from causing poor
performance on large histories, this does not match the default
behavior of `git rev-list`, which does not rewrite parent SHAs unless
asked to via --parents/--children.
Add a new method setRewriteParents() to RevWalk to disable this
behavior. Continue rewriting parents by default to maintain backwards
compatibility.
Konrad Kügler [Sat, 3 May 2014 13:00:47 +0000 (15:00 +0200)]
blame: Fix merges, where merge result differs only by whitespace
When blaming a merge commit with "Ignore whitespace changes" enabled,
don't discard blame candidates for other parents when we encounter a
parent that only has whitespace changes compared to the merge result.
The algorithm early prepares parents for blaming, removing the
appropriate blame regions from the list of regions still to blame. Only
at the end, the prepared blame candidates are submitted for blaming.
When looking at a non-first parent which only differs in whitespace to
the merge result, it submitted that parent, but only to blame it for the
(usually few) lines not already prepared to blame on other parents. Due
to an early return the blame candidates for the previous parents were
forgotten, leaving many lines unannotated.
bug: 433024
Change-Id: I43c9caf2078b92b05e652dbed2192568907bf199 Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
When JGit uses bitmaps (which is the case after a gc), the push command
doesn't go through the code where MissingObjectExceptions are caught
for remote objects not found locally.
Fixed by removing earlier non-locally-found remote objects.
This was seen withing gerrit, see:
https://code.google.com/p/gerrit/issues/detail?id=2025
Bug: 426044
Change-Id: Ieda718a0530e3680036edfa0963ab88fdd1362c0 Signed-off-by: Jean-Jacques Lafay <jeanjacques.lafay@gmail.com> Signed-off-by: Doug Kelly <dougk.ff7@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Robin Rosenberg [Sat, 26 Apr 2014 11:05:53 +0000 (13:05 +0200)]
Fix ArrayIndexOutOfBoundsException in CreateBranchCommand
If remote name contains / or there was a branch directly under the
refs/remotes namespace (wrong) the computation of remote name and
suggested local branch name would fail. Fix this by looking at the
configured remotes. A ref under refs/remotes that does not match a
remote configuration is not considered a remote tracking branch anymore.
This patch does not fix all similar errors in EGit/JGit.
* changes:
Commit changes generated during repo command
Added implementation of copyfile rule.
Added groups support to repo subcommand.
Added the command line of jgit repo.
Implemented first part of the repo sub-command.
Doug Kelly [Thu, 24 Apr 2014 19:37:27 +0000 (14:37 -0500)]
Automatically reload known_hosts file
JGit caches the contents of the known_hosts file within JSch when
first started, and never attempts to re-read it. If the contents
change (such as when using Gerrit replication), the new host will
never be found.
On failures, try reloading the knonwn_hosts and retry the
connection, in addition to reloading the credentials.
Change-Id: I980c4f4003f2a48c71b9b47c51e640d1e7742f58 Signed-off-by: Doug Kelly <dougk.ff7@gmail.com>
Doug Kelly [Thu, 24 Apr 2014 00:33:18 +0000 (19:33 -0500)]
Remove streaming delta support from JGit
Streaming packed deltas is so slow that it never feasibly completes
(it will take hours for it to stream a few hundred megabytes on
relatively fast systems with a large amount of storage). This
was indicated as a "failed experiment" by Shawn in the following
mailing list post:
http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg01674.html
Change-Id: Idc12f59e37b122f13856d7b533a5af9d8867a8a5 Signed-off-by: Doug Kelly <dougk.ff7@gmail.com>
* changes:
blame: Reuse existing blameEntireRegionOnParent method
blame: Remove unnecessary curly braces around single statement if
blame: Allow candidate to manage its setup before output
blame: Do not update candidate regionList during output
blame: Only use computeRange if -L was requested
blame: Format commit and author only once per range
When a commit is blamed for multiple lines of the result file the
command line interface prints the same text before each line in that
span. Format these strings once and reuse them as the line prefix.
For long files (e.g. 2425 lines of ReceiveCommits.java in Gerrit)
this can save as much as 20ms during the output phase of the command
line blame program.
Skipping directly to the parent is already possible with an existing
helper method. Update the source path (to follow the rename) and then
use the existing code path to push the parent inside the current entry.
blame: Allow candidate to manage its setup before output
Pass in the RevWalk and let the candidate decide how to prepare itself
for output. This removes the conditional for the missing sourceCommit,
as candidates missing a commit can override the method with a no-op.
blame: Do not update candidate regionList during output
Instead of updating the candidate's regionList field to iterate
through the linked list of regions, use a special purpose field
in the BlameGenerator. This allows the candidate to be unmodified.
If an error occurs in command line option parsing the error message
may be stuck in a Java level buffer. Flush the stream to ensure
everything is made available to the calling process or terminal.
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>
projects / jgit.git / log