Skip to main content
aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2011-05-02JGit 0.12.1v0.12.1stable-0.12Matthias Sohn2-10/+10
Change-Id: Ia6e58b466fa3ef7ddd61b40f2ad44141fe8786c4 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2011-04-18Make running static checks configurable in maven buildMatthias Sohn1-33/+0
In order to run the static checks run: mvn -P static-checks clean install Change-Id: I14077498a04be986ded123ddbfc97da8f9bc3130 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2011-02-12Qualify post 0.11 buildsMatthias Sohn2-10/+10
Change-Id: Ibcef4fc4c986c2cda01e943d16aa1c53eff99f25 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2011-02-11JGit 0.11.1v0.11.1Matthias Sohn2-10/+10
Change-Id: I9ac2fdfb4326536502964ba614d37d0bd103f524 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2010-12-17Qualify post 0.10 buildsMatthias Sohn2-10/+10
Change-Id: Ifcb8fdea95286779c8aea6bf4d7647e8c1c98d63 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2010-12-17Qualify post 0.10.1 buildsstable-0.10Matthias Sohn2-10/+10
Change-Id: I320f1f739f3689daf11d532a55ae1133785aec8e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2010-12-17JGit 0.10.1v0.10.1Matthias Sohn2-10/+10
Change-Id: I4a46d35d354193e5d4f28ef7dfae75944be8ffcf Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2010-11-10Implement command line support for CredentialsProviderShawn O. Pearce3-186/+206
Instead of configuring the JSch session factory, configure a more generic CredentialsProvider, which will work for other transport types such as http, in addition to the existing ssh. Change-Id: I22b13303c17e654ba6720edf4be2ef15fe29537a Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-10-28Fix FindBugs and Eclipse warnings in org.eclipse.jgit.uiRobin Stocker4-3/+13
Change-Id: Ie6b3ff7d470cc9b7044fd6288cbf86dcc58220eb
2010-10-23Add FindBugs and CPD to the build.Chris Aniszczyk1-0/+33
We need to use findbugs-maven-plugin:2.3.2-SNAPSHOT since otherwise build fails with maven-3.0 [1], [2]. We should switch to the release version as soon as this becomes available. [1] http://www.sonatype.com/people/2010/10/maven-3-0-has-landed/ [2] http://jira.codehaus.org/browse/MFINDBUGS-122 Bug: 327799 Change-Id: I1c57f81cf6f0450e56411881488c4ee754e458e3 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2010-09-17Qualify builds as 0.10.0Shawn O. Pearce2-9/+9
Change-Id: I54815c85b32b9492c059064b39f48677e68c5e90 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-09-15Qualify post-0.9.3 buildsstable-0.9Matthias Sohn2-9/+9
Change-Id: Ideab4923a5d8055f0e8a36ddcf0bc8adbf71c329 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2010-09-15JGit 0.9.3v0.9.3Matthias Sohn2-9/+9
Change-Id: I114106f3286c36f7d5e136748a7e5130f4da163f Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2010-09-15Qualify post-0.9.1 buildsMatthias Sohn2-9/+9
Change-Id: I07a3391de03379f32ecfd055d45750e3860b2be4 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2010-09-15JGit 0.9.1v0.9.1Matthias Sohn2-9/+9
Change-Id: Ic411b1b8a7e6039ae3ff567e2c9cdd5db84f4d41 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2010-08-28Revert "Hide Maven target directories from Eclipse"Robin Rosenberg1-11/+0
This reverts commit db4c516f673e4c274e55adc27a95891c52a5aba8 since it breaks compatibility with Eclipse 3.5 which can no longer import the projects Bug: 323390 Change-Id: I3cc91364a6747cfcb4c611a9be5258f81562f726
2010-08-26Run formatter on edited lines via save actionChris Aniszczyk1-3/+4
Updates the project level settings to run the formatter on save on only on the edited lines. Change-Id: I26dd69d0c95e6d73f9fdf7031f3c1dbf3becbb79 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2010-08-08Hide Maven target directories from EclipseRobin Rosenberg1-0/+11
Change-Id: I64f12a35423a90ced9c9bc83f6869d8ed766dd35 Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
2010-06-14Merge changes ↵Shawn Pearce2-3/+7
I53f71dc0,I3a899a3a,I3e8bd245,Ie7c9db83,If396326e,I6f4cf8da,I3bf96dd0,I3a2a43a1,I292fe88c,Ia1cf40cf * changes: git-servlet: Fix comparing uploadFactory with the wrong DISABLED instance Prefer static inner classes Override equals for SwingLane since super class PlotLane defines it Make sure a Stream is closed upon errors in IpLogGenerator Make constant static in RebuildCommitGraph Make inner classes static in http code Cache filemode in GitIndex Remove unused parent field in PlotLane Removed unused repo field in WorkDirCheckout Extend DiffFormatter API to simplify styling
2010-06-14Start 0.9 developmentShawn O. Pearce2-9/+9
Change-Id: I84173ece5100f1fcb78168e2e102b649d9466c08 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-06-13Prefer static inner classesRobin Rosenberg1-3/+3
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
2010-06-13Override equals for SwingLane since super class PlotLane defines itRobin Rosenberg1-0/+4
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
2010-06-02Qualify post-0.8.1 buildsShawn O. Pearce2-9/+9
Change-Id: Id86e5876b2f684b2a272c07061a276b054ba410d Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-06-02JGit 0.8.1v0.8.1Shawn O. Pearce2-9/+9
Change-Id: I3d4ac7d0617a3575019e2ed748ed2a298a988340 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-05-19Externalize strings from JGitSasa Zivkov8-8/+91
The strings are externalized into the root resource bundles. The resource bundles are stored under the new "resources" source folder to get proper maven build. Strings from tests are, in general, not externalized. Only in cases where it was necessary to make the test pass the strings were externalized. This was typically necessary in cases where e.getMessage() was used in assert and the exception message was slightly changed due to reuse of the externalized strings. Change-Id: Ic0f29c80b9a54fcec8320d8539a3e112852a1f7b Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>
2010-04-05JGit plugin not compatible with Eclipse 3.4Robin Rosenberg1-3/+3
The JSch bundle in Eclipse 3.4 does not export its packages with version numbers. Use Require-Bundle on version 0.1.37 that comes with Eclipse 3.4 There is no 0.1.37 in the maven repositories so the pom still refers to 0.1.41 so the build can get the compile time dependencies right. Bug: 308031 CQ: 3904 jsch Version: 0.1.37 (using Orbit CQ2014) Change-Id: I12eba86bfbe584560c213882ebba58bf1f9fa0c1 Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
2010-03-21Qualify builds as 0.8.0Shawn O. Pearce2-8/+8
Since the API is changing relative to 0.7.0, we'll call our next release 0.8.1. But until that gets released, builds from master will be 0.8.0.qualifier. Change-Id: I921e984f51ce498610c09e0db21be72a533fee88 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-02-03Cleanup OSGi Import-Package specifications to use versionsShawn O. Pearce1-6/+6
Actually set the range of versions we are willing to accept for each package we import, lest we import something in the future that isn't compatible with our needs. Change-Id: I25dbbb9eaabe852631b677e0c608792b3ed97532 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-23Correct bundle, provider names to be consistentShawn O. Pearce1-2/+2
Technically our project name is "JGit", not "Java Git". In fact there is already another project called "JavaGit" (no space) that we don't want to become confused with. Ensure we always call ourselves "JGit" in user visible assets, like the bundle name. Other Eclipse products list their provider as "Eclipse.org", not "eclipse.org". So list ourselves that way in all of our plugin.properties files. Change-Id: Ibcea1cd6dda2af757a8584099619fc23b7779a84 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-23Merge branch 'ref-abstract'Shawn O. Pearce1-1/+2
* ref-abstract: Optimize RefAdvertiser performance by avoiding sorting branch: Add -m option to rename a branch Replace writeSymref with RefUpdate.link Rewrite reference handling to be abstract and accurate Create new RefList and RefMap utility types Change-Id: If43aacf5aa4013edbd0a6e84d84c4f9e94de5be0
2010-01-23Rewrite reference handling to be abstract and accurateShawn O. Pearce1-1/+2
This commit actually does three major changes to the way references are handled within JGit. Unfortunately they were easier to do as a single massive commit than to break them up into smaller units. Disambiguate symbolic references: --------------------------------- Reporting a symbolic reference such as HEAD as though it were any other normal reference like refs/heads/master causes subtle programming errors. We have been bitten by this error on several occasions, as have some downstream applications written by myself. Instead of reporting HEAD as a reference whose name differs from its "original name", report it as an actual SymbolicRef object that the application can test the type and examine the target of. With this change, Ref is now an abstract type with different subclasses for the different types. In the classical example of "HEAD" being a symbolic reference to branch "refs/heads/master", the Repository.getAllRefs() method will now return: Map<String, Ref> all = repository.getAllRefs(); SymbolicRef HEAD = (SymbolicRef) all.get("HEAD"); ObjectIdRef master = (ObjectIdRef) all.get("refs/heads/master"); assertSame(master, HEAD.getTarget()); assertSame(master.getObjectId(), HEAD.getObjectId()); assertEquals("HEAD", HEAD.getName()); assertEquals("refs/heads/master", master.getName()); A nice side-effect of this change is the storage type of the symbolic reference is no longer ambiguous with the storge type of the underlying reference it targets. In the above example, if master was only available in the packed-refs file, then the following is also true: assertSame(Ref.Storage.LOOSE, HEAD.getStorage()); assertSame(Ref.Storage.PACKED, master.getStorage()); (Prior to this change we returned the ambiguous storage of LOOSE_PACKED for HEAD, which was confusing since it wasn't actually true on disk). Another nice side-effect of this change is all intermediate symbolic references are preserved, and are therefore visible to the application when they walk the target chain. We can now correctly inspect chains of symbolic references. As a result of this change the Ref.getOrigName() method has been removed from the API. Applications should identify a symbolic reference by testing for isSymbolic() and not by using an arcane string comparsion between properties. Abstract the RefDatabase storage: --------------------------------- RefDatabase is now abstract, similar to ObjectDatabase, and a new concrete implementation called RefDirectory is used for the traditional on-disk storage layout. In the future we plan to support additional implementations, such as a pure in-memory RefDatabase for unit testing purposes. Optimize RefDirectory: ---------------------- The implementation of the in-memory reference cache, reading, and update routines has been completely rewritten. Much of the code was heavily borrowed or cribbed from the prior implementation, so copyright notices have been left intact as much as possible. The RefDirectory cache no longer confuses symbolic references with normal references. This permits the cache to resolve the value of a symbolic reference as late as possible, ensuring it is always current, without needing to maintain reverse pointers. The cache is now 2 sorted RefLists, rather than 3 HashMaps. Using sorted lists allows the implementation to reduce the in-memory footprint when storing many refs. Using specialized types for the elements allows the code to avoid additional map lookups for auxiliary stat information. To improve scan time during getRefs(), the lists are returned via a copy-on-write contract. Most callers of getRefs() do not modify the returned collections, so the copy-on-write semantics improves access on repositories with a large number of packed references. Iterator traversals of the returned Map<String,Ref> are performed using a simple merge-join of the two cache lists, ensuring we can perform the entire traversal in linear time as a function of the number of references: O(PackedRefs + LooseRefs). Scans of the loose reference space to update the cache run in O(LooseRefs log LooseRefs) time, as the directory contents are sorted before being merged against the in-memory cache. Since the majority of stable references are kept packed, there typically are only a handful of reference names to be sorted, so the sorting cost should not be very high. Locking is reduced during getRefs() by taking advantage of the copy-on-write semantics of the improved cache data structure. This permits concurrent readers to pull back references without blocking each other. If there is contention updating the cache during a scan, one or more updates are simply skipped and will get picked up again in a future scan. Writing to the $GIT_DIR/packed-refs during reference delete is now fully atomic. The file is locked, reparsed fresh, and written back out if a change is necessary. This avoids all race conditions with concurrent external updates of the packed-refs file. The RefLogWriter class has been fully folded into RefDirectory and is therefore deleted. Maintaining the reference's log is the responsiblity of the database implementation, and not all implementations will use java.io for access. Future work still remains to be done to abstract the ReflogReader class away from local disk IO. Change-Id: I26b9287c45a4b2d2be35ba2849daa316f5eec85d Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-23Use build timestamp as OSGi version qualifierMatthias Sohn1-1/+6
Translate the version qualifier using maven-antrun-plugin since we want manifest-first and currently cannot rely on Tycho for the JGit build. Introduce property for Eclipse p2 repository to enable builds against other Eclipse versions. Change-Id: I62c4e77ae91fe17f56c5a5338d53828d4e225395 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2010-01-12Finish removing Apache Felix maven-bundle-pluginShawn O. Pearce2-18/+1
Since Robin reverted using the maven-bundle-plugin to produce the OSGi manifest, there is no reason for us to reference it from our build process anymore. Also, when Robin reverted the to the Eclipse way of doing things, we failed to update the ignore files to ignore our generated files but not ignore our tracked .classpath. Finally, we cannot delete the MANIFEST.MF file during a Maven build, as this is once again a source file. Change-Id: I53f77f2002cb4285f728968829560e835651e188 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-01-10Partial revert "Switch build to Apache Felix maven-bundle-plugin"Robin Rosenberg6-11/+62
This restores the ability to build using just Eclipse without strange procedures, extra plugins and it is again possible to work on both JGit and EGit in the same Eclipse workspace with ease. Change-Id: I0af08127d507fbce186f428f1cdeff280f0ddcda Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
2009-12-28Switch build to Apache Felix maven-bundle-pluginShawn O. Pearce7-65/+31
Tycho isn't production ready for projects like JGit to be using as their primary build driver. Some problems we ran into with Tycho 0.6.0 that are preventing us from using it are: * Tycho can't run offline The P2 artifact resolver cannot perform its work offline. If the build system has no network connection, it cannot compile a project through Tycho. This is insane for a distributed version control system where developers are used to being offline during development and local testing. * Magic state in ~/.m2/repository/.meta/p2-metadata.properties Earlier iterations of this patch tried to use a hybrid build, where Tycho was only used for the Eclipse specific feature and P2 update site, and maven-bundle-plugin was used for the other code. This build seemed to work, but only due to magic Tycho specific state held in my local home directory. This means builds are not consistently repeatable across systems, and lead me to believe I had a valid build, when in fact I did not. * Manifest-first build produces incomplete POMs The POM created by the manifest-first build format does not contain the dependency chain, leading a downstream consumer to not import the runtime dependencies necessary to execute the bundle it has imported. In JGit's case, this means JSch isn't included in our dependency chain. * Manifest-first build produces POMs unreadable by Maven 2.x JGit has existing application consumers who are relying on Maven 2.x builds. Forcing them to step up to an alpha release of Maven 3 is simply unacceptable. * OSGi bundle export data management is tedious Editing each of our pom.xml files to mark a new release is difficult enough as it is. Editing every MANIFEST.MF file to list our exported packages and their current version number is something a machine should do, not a human. Yet the Tycho OSGi way unfortunately demands that a human do this work. * OSGi bundle import data management is tedious There isn't a way in the MANIFEST.MF file format to reuse the same version tags across all of our imports, but we want to have a consistent view of our dependencies when we compile JGit. After wasting more than 2 full days trying to get Tycho to work, I've decided its a lost cause right now. We need to be chasing down bugs and critical features, not trying to bridge the gap between the stable Maven repository format and the undocumented P2 format used only by Eclipse. So, switch the build to use Apache Felix's maven-bundle-plugin. This is the same plugin Jetty uses to produce their OSGi bundle manifests, and is the same plugin used by the Apache Felix project, which is an open-source OSGi runtime. It has a reasonable number of folks using it for production builds, and is running on top of the stable Maven 2.x code base. With this switch we get automatically generated MANIFEST.MF files based on reasonably sane default rules, which reduces the amount of things we have to maintain by hand. When necessary, we can add a few lines of XML to our POMs to tweak the output. Our build artifacts are still fully compatible with Maven 2.x, so any downstream consumers are still able to use our build products, without stepping up to Maven 3.x. Our artifacts are also valid as OSGi bundles, provided they are organized on disk into a repository that the runtime can read. With maven-bundle-plugin the build runs offline, as much as Maven 2.x is able to run offline anyway, so we're able to return to a distributed development environment again. By generating MANIFEST.MF at the top level of each project (and therefore outside of the target directory), we're still compatible with Eclipse's PDE tooling. Our projects can be imported as standard Maven projects using the m2eclipse plugin, but the PDE will think they are vaild plugins and make them available for plugin builds, or while debugging another workbench. This change also completely removes Tycho from the build. Unfortunately, Tycho 0.6.0's pom-first dependency resolver is broken when resolving a pom-first plugin bundle through a manifest-first feature package, so bundle org.eclipse.jgit can't be resolved, even though it might actually exist in the local Maven repository. Rather than fight with Tycho any further, I'm just declaring it plugina-non-grata and ripping it out of the build. Since there are very few tools to build a P2 format repository, and no documentation on how to create one without running the Eclipse UI manually by poking buttons, I'm declaring that we are not going to produce a P2 update site from our automated builds. Change-Id: If7938a86fb0cc8e25099028d832dbd38110b9124 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-11-03Move AWT based SSH authenticator to ui bundleShawn O. Pearce2-2/+190
This way SWT based applications don't wind up loading this AWT based code when using SSH. Change-Id: I9080f3dd029c2a087e6b687480018997cc5c5d23 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-11-03Refactor the cached Authenticator data out of AwtAuthenticatorShawn O. Pearce1-68/+8
This makes it easier to swap out authenticator implementations and yet still rely upon being able to configure at least one Authenticator instance in the JVM and program it with data obtained from outside of the user interface. Change-Id: I8c1a0eb8acee1d306f4c3b40a790b7fa0c3abb70 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-11-03Refactor our Maven build to be modularShawn O. Pearce3-1/+97
Drop our simple and stupid jgit.sh and instead rely upon Maven for the command line based build. Maven is relatively simple to download and install, and doesn't require the entire Eclipse IDE. To avoid too much refactoring of the current code we reuse the existing src/ directory within each plugin, and treat each of the existing OSGI bundles as one Maven artifact. The command line wrapper jgit.sh no longer works in the uncompiled state, as we don't know where to obtain our JSch or args4j from. Developers will now need to compile it with `mvn package`, or run our Main class from within an IDE which has the proper classpath. Bug: 291265 Change-Id: I355e95fa92fa7502651091d2b651be6917a26805 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-10-31Move AWT UI code to new org.eclipse.jgit.ui bundleMykola Nikishov15-0/+1195
This new UI bundle contains the org.eclipse.jgit.awtui package, which was moved out of the org.eclipse.jgit bundle. org.eclipse.jgit.pgm depends on org.eclipse.jgit.ui, so we need to update the classpath and make_jgit.sh to include it. This move takes the awtui classes out of the Maven build, which means we are no longer able to distribute these classes to our downstream Maven customers. The entire Maven package structure needs to be overhauled so that Eclipse bundle matches 1:1 with the Maven artifact. Bug: https://bugs.eclipse.org/291124 Change-Id: Ibf1a9968387e3d11fdce54592f710ec4cc7f1ddb Signed-off-by: Mykola Nikishov <mn@mn.com.ua> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

    Back to the top