* stable-2.0:
Prepare post v2.0.0.201206130900-r builds
JGit v2.0.0.201206130900-r
Add org.eclipse.jgit.pgm.feature to enable consumption via p2
Do not set core.autocrlf when creating repo
Change-Id: Ifdd71a6bc14d9c79f4433ebc3b53bf0042a4d4c8
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Orion wants to consume the pgm bundle from a p2 repository in their
build. Also add corresponding source bundle and feature to provision
sources via a target platform.
Bug: 373789
Change-Id: I0016ee155553c546606b63d310666eb10bd997e1
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
core.autorlf defaults to false, but can be set in the user or
"system" config files. Note that EGit/JGit may not know
where the "system" config file is located.
Also fix pgm's ConfigTest which depends on default repository
configuration.
Bug: 382067
Change-Id: I2c698a76e30d968e7f351b4f5a2195f0b124f62f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Include some behaviors that were not clear to me until I had used it a
few times.
Warn about broken behavior for capture groups that do not match. It
would be nice to support these, but even for the cases where it's
clear what the behavior should be, it would be infeasible to
implement.
For example, consider the second group of the regex "(/a)/b(/c)?"
matched against the path "/a/b". We might want getServletPath() to
return "/a/b" and getPathInfo() to return null, but this is hard to
implement: there's no easy way to say "the substring up to the point
where (/c) would have matched if it were in the string even though
it's not." And even if we could, it's not clear there is even a right
answer in the general case.
Moreover, ideally we could warn about such broken patterns at servlet
initialization time, rather than at runtime, but even answering the
question of whether there are capture groups that might not match
requires more customized regular expression parsing than we want to
embark on. Hence, the best we can do is document how it fails.
Change-Id: I7bd5011f5bd387f9345a0e79b22a4d7ed918a190
By Robin Rosenberg (6) and others
via Gerrit Code Review @ Eclipse.org (2) and Matthias Sohn (1)
* stable-2.0:
Prepare next 2.0.0-SNAPSHOT builds
JGit v2.0.0.201206060730-rc3
Remove Jetty p2 repository from Maven build
Get rid of warnings about empty statments
Removed unused parameters from private methods
cleanup: Remove unused declarations
Make FS OS X detection work for OpenJDK
Use working tree iterator to compare file modes
Further cleanup of exceptions in Git API
Update build to use Tycho 0.15.0
Throw formal CheckoutConflictException on hard reset
Configure maven-source-plugin execution in parent POM
Support gitdir: refs in BaseRepositoryBuilder.findGitDir
Relax RevisionSyntaxException to an IllegalArgumentException
Change-Id: I05727693e0c9e762d4fc220ceadcd5a5bfb11d0d
This updates the timestamp of files that are not touched during
checkout. Otherwise the timestamp will always be zero, causing the
IndexDiffFilter to always calculate the checksum of file contents.
Change-Id: I18047f5725f22811bb4194ca1d3a3cac56074183
This reference is not required and would force all JGit consumers to
switch to Maven 3 and Tycho which isn't desirable.
Bug: http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg01687.html
Change-Id: Iecf7c5aad46bb05fce0455cc8127aee2f679848c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
In HtttpAuthMethod there were comments, but not in a style
that Eclipse recognizes.
Change-Id: I64f55b27143f8badcefbb419d3951f2a26b87d5f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* changes:
Use BatchRefUpdate for tracking refs in FetchProcess
Batch reference updates together for storage
Expose ReceiveCommand.updateType to check for UPDATE_NONFASTFORWARD
Reject non-fast-forwards earlier in BaseReceivePack
Add isModeDifferent method to WorkingTreeIterator
that compares mode with consideration of the
core.filemode setting in the config.
Bug: 379004
Change-Id: I07335300d787a69c3d1608242238991d5b5214ac
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
- Translate internal exceptions to corresponding API exception
- Do not catch GitAPI exceptions internally to an internal
exception. Just pass them to caller
- Mention thrown exceptions in javadoc
Change-Id: I9044cf86d2b0bcc8b63b7cc016e1bf0055a62053
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Also use packaging type eclipse-repository to create the p2 repository
since Tycho fixed bug 368596 which we worked around using packaging type
eclipse-update-site.
Change-Id: Id4ee884027d55cd2d43e8a6ef58a67f74ab488e4
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This will allow calling classes to have access to the
conflicts that occurred during the attempted checkout.
Even though setFailOnConflict(false) is called on the
DirCacheCheckout a CheckoutConflictException can still
be thrown if cleanup fails.
Change-Id: Iea7ad3176a1b0e8606a643de8945e276718eb3ce
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This ensures all modules will have source jars built
Change-Id: I11a762f54cc8b059eff3bd99138a7efa9723b19f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This allows findGitDir to be used for repositories containing
a .git file with a gitdir: ref to the repository's directory
such as submodule repositories that point to a folder under the
parent repository's .git/modules folder
Change-Id: I2f1ec7215a2208aa90511c065cadc7e816522f62
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
PackWriter supports excluding objects from being written to the pack.
You may specify a PackIndex which lists all those objects which should
not go into the new pack. This feature was broken because not all
commits have been checked whether they should be excluded or not. For
other object types the exclude algorithm worked. This commit adds the
missing check.
Change-Id: Id0047098393641ccba784c58b8325175c22fcece
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This change is required by egit's lazy loading of the body in the
history view when the walk is started with setRetainBody(false).
Change-Id: I9291ba8c34c8744bc009b1bd302ed28bfa4e9476
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
This reverts commit 0c6e7d7127 which
didn't work since package imports need to be different with Jetty 7.5
and 7.6. Jetty 7.6 can be installed into Eclipse SDK 3.7.2 so rather
require Jetty 7.6 instead of adding a lot of reflective code to
workaround these incompatible changes.
Change-Id: I7eb6413ecf2bc4ad7bef0c70cde45ae3fde02b2f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Class Constraint was moved from package org.eclipse.jetty.http.security
in Jetty 7.5 to package org.eclipse.jetty.util.security in Jetty 7.6.
Hence also import package org.eclipse.jetty.security, then also Jetty
7.5, coming with Indigo, can be used to run JGit HTTP tests.
Change-Id: I26c38ec9f51b0a4fb62e1aa9f2266ada7bb2fa0c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This reverts commit 24a0f47e32 and
updates JGit dependencies to use the latest available Jetty 7.x
release. We can't use Jetty 8.x since it depends on Servlet API 3.0
which requires Java 6 but JGit still wants to support Java 5.
Use one of the target platforms defined in
Ibf67a6d3539fa0708a3e5dbe44fb899c56fbd8ed to work with that in Eclipse.
Change-Id: I343273d994dc7b6e0287c604e5926ff77d5b585b
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Write the old object id from the RefUpdate to the
ORIG_HEAD file after the update completes.
Add two new convenience methods to Repository to read
and write the ORIG_HEAD reference similar to the methods
for reading/writing CHERRY_PICK_HEAD and MERGE_HEAD.
Bug: 375525
Change-Id: I120b3b2cd3b1ddae88fce435285bae15cbf96f5e
This reduces the number of hard-coded version numbers we have to touch
with every release.
Change-Id: I0f2e910423d3db081b644968cd0d6a89178ba12a
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
All commands should throw a GitAPIException so new exceptions can be
added without breaking the builds of old code, i.e. anyone that calls
a Git API should catch GitAPIException and not just the currently known
exceptions.
Now the only checked exceptions on Git API calls are GitException and
subclasses of it. New checked exceptions that are subclasses of
GitException may be added without breaking the API.
Javadoc for GitAPIException is declared on GitCommand and
inherited to subclasses. JGitInternalException is not explicitly
documented anymore.
Unfortunately this change itself breaks the API. The intention is
that it shall be possible to add new checked subclasses of
GitAPIException without breaking the API.
Bug: 366914
EGit-Change-Id: I50380f13fc82c22d0036f47c7859cc3a77e767c5
Change-Id: I50380f13fc82c22d0036f47c7859cc3a77e767c5
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This is needed to allow jumping to a selected commit when loading
history incrementally.
Change-Id: Id3b97d88d3b4b2d67561b11f8810cb88fe040823
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Previously if a packed-refs file was racily clean then there
was a 2.5 second window in which each call to getPackedRefs
would increment the mod count causing a RefsChangedEvent to be
fired since the FileSnapshot would report the file as modified.
If a RefsChangedListener called getRef/getRefs from the
onRefsChanged method then a StackOverflowError could occur
since the stack could be exhausted before the 2.5 second
window expired and the packed-refs file would no longer
report being modified.
Now a SHA-1 is computed of the packed-refs file and the
mod count is only incremented when the packed refs are
successfully set and the id of the new packed-refs file
does not match the id of the old packed-refs file.
Change-Id: I8cab6e5929479ed748812b8598c7628370e79697
Matthias Sohn