Refactors HttpAuthMethod to support more authentication methods,
still sorted by priority orders.
Bug: 428836
Change-Id: I049c1742e7afbc51f3f6033fa4d471b344813cfa
Signed-off-by: Laurent Goujon <lgoujon@twitter.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Sun HttpURLConnection is able to handle authentication like SPNEGO without
caller intervention. However, there are some restrictions:
- do not need user direct input (user,password for example)
- it doesn't work when request body is chunked/streamed (because it cannot be
replayed)
Unfortunately there is no real way to leverage HttpURLConnection authentication
work as the authentication header is stripped off the request before returning
to the caller. There's also no way to explicitly disable authentication in
HttpURLConnection (SPNEGO auth will always be attempted if a valid token can be
created by GSSAPI).
This is an issue for jgit since it is expected that the first request will be
used to detect authentication method, and reuse for the subsequent requests.
This patch modifies TransportHTTP to detect authentication done in the background
by HttpURLConnection and sets the jgit authentication method accordingly so it will
always work for future requests (assuming that the authentication method used by
HttpURLConnection is also supported by jgit).
Bug: 428836
Change-Id: I79f3b70ca2b8377e20da8e6a01914e43e96595ce
Signed-off-by: Laurent Goujon <lgoujon@twitter.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Adds a factory class for GSSManager. GSSManager is already a factory class but
it doesn't work well with SPNEGO HTTP authentication unless the
javax.security.auth.useSubjectCredsOnly system property is set to false.
On Sun JDK, Sun GSSManagerImpl can be configured directly for SPNEGO auth
(without setting any system property). For a better experience, the class
availability is detected by reflection and used instead.
Detection is only done once, and fallbacks to org.ietf.jgss.GSSManager.
Bug: 428836
Change-Id: Idb9123d1f4013966919db43043ec959d4b133ae2
Signed-off-by: Laurent Goujon <lgoujon@twitter.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
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
* testSymlinkNotModifiedThoughNormalized
* testSymlinkModifiedNotNormalized
They all failed in the same way:
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:
https://github.com/eclipse/jgit/blob/6d724dcd/org.eclipse.jgit/src/org/eclipse/jgit/treewalk/FileTreeIterator.java#L139
Whether your tests appeared to pass or fail was dependent on the returned
order of files from `listFiles()`:
* ['.git', 'link'] - PASS (Eclipse Hudson appears to get this ordering)
* ['link', '.git'] - FAIL (My env, Ubuntu 14.04/Java 1.7.0_55)
The tree-iterator passes the resulting `FileEntry`s to it's init() method:
https://github.com/eclipse/jgit/blob/6d724dcd/org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java#L639-L665
... 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:
* ['.git', 'link'] -> ['link', 'link']
* ['link', '.git'] -> ['link', '.git']
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.
Change-Id: Ie58a7bc76b740ee52881ebf555564a74379028d6
Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com>
This partially reverts 6de12836d7.
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.
Change-Id: Ic6d5fff22acb5ab6485614a07bdb388e8c336679
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>
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>
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>
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.
org.eclipse.jgit.api.ArchiveCommand: Adding setPaths(String... paths)
method.
Change-Id: Iedcd40fbfd71238b0088174bbe2717fae196e047
Signed-off-by: Shaul Zorea <shaulzorea@gmail.com>
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>
Change-Id: I587aae0ad217ed092f061682ffa66c724f221096
Signed-off-by: Tomasz Zarna <tomasz.zarna@tasktop.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
- 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>
* changes:
Do not rewrite parents in RevWalkTextBuiltins
RevWalk: Allow disabling parent rewriting
RevWalkTextBuiltin: Add -n to limit number of commits returned
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.
Change-Id: I9ba0e70fe6d5f49f975b71eea46f93198900f37d
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.
Change-Id: I1f38e05526071c75ca58095e312663de5e6f334d
Using the lane position and other data for equals/hashCode is not
useful.
Change-Id: I7af151d8a84544a77a486474c8ac71dd80090c66
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
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>
This makes it easy to edit the pom.xml from within Eclipse.
Change-Id: I4718217caadbfe892b7cbb557e0d3d6b40d48321
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
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.
Bug: 411002
Bug: 400414
Change-Id: I2515a6ed05f9104c387ce4e43b24dae942ae2473
Instead of requiring the caller to know how to list remote
names or parse remote branch names, add a few utilities for
that.
Change-Id: Ib6b2403532f4abbce594a03c0b9da49d30b19f70
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
* 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.
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>
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>
Laurent Goujon
Roberto Tyley
Shawn Pearce
Robin Rosenberg
Konrad Kügler
Matthias Sohn
Shaul Zorea
Christian Halstrick
Tomasz Zarna
Yuxuan 'fishy' Wang
Dave Borowitz
Laurent Goubet
Shawn Pearce
Jean-Jacques Lafay
Bogdan Gheorghe
Doug Kelly