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>

When running jgit from inside Eclipse (e.g. rightclick on project
org.eclipse.jgit.pgm and select Run as->Java application) no commands
are found. This is because the commands are loaded from a resource file
/META-INF/services/org.eclipse.jgit.pgm.TextBuiltin and this file is
not anymore on the classpath.
I fixed this by modifying .classpath to contain the META-INF directory.

Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>

The new plugin contains the bulk of the logic to scan a Git repository,
and query IPZilla, in order to produce an XML formatted IP log for the
requested revision of any Git based project.  This plugin is suitable
for embedding into a servlet container, or into the Eclipse workbench.

The command line pgm package knows how to invoke this plugin through
the eclipse-iplog subcommand, permitting storage of the resulting
log as a local XML file.

Change-Id: If01d9d98d07096db6980292bd5f91618c55d00be
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

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>

Change-Id: I7cf8e43344eaf301592fba0c178e04daad930f9a
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

By using RefUpdate for symbolic reference creation we can reuse
the logic related to updating the reflog with the event, without
needing to expose something such as the legacy ReflogWriter class
(which we no longer have).

Applications using writeSymref must update their code to use the
new pattern of changing the reference through the updateRef method:

    String refName = "refs/heads/master";
    RefUpdate u = repository.updateRef(Constants.HEAD);
    u.setRefLogMessage("checkout: moving to " + refName, false);
    switch (u.link(refName)) {
    case NEW:
    case FORCED:
    case NO_CHANGE:
        // A successful update of the reference
        break;
    default:
        // Handle the failure, e.g. for older behavior
        throw new IOException(u.getResult());
    }

Change-Id: I1093e1ec2970147978a786cfdd0a75d0aebf8010
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

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>

Not all occurrences of ".git" are replaced by this constant, only
those where it actually refers to the directory with that name, i.e
not the ".git" directory suffix.

Asserts and comment are also excluded from replacement.

Change-Id: I65a9da89aedd53817f2ea3eaab4f9c2bed35d7ee
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>

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>

There was a missing dependency.

Change-Id: Ib7b9f05ee4c7c2bd7760ce44a7c2cd72759d514d
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>

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>

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>

This makes the jgit command line behave like the C Git implementation
in the respect.

These variables are not recognized in the core, though we add support
to do the overrides there. Hence other users of the JGit library, like
the Eclipse plugin and others, will not be affected.

GIT_DIR
	The location of the ".git" directory.

GIT_WORK_TREE
	The location of the work tree.

GIT_INDEX_FILE
	The location of the index file.

GIT_CEILING_DIRECTORIES
	A colon (semicolon on Windows) separated list of paths that
	which JGit will not cross when looking for the .git directory.

GIT_OBJECT_DIRECTORY
	The location of the objects directory under which objects are
	stored.

GIT_ALTERNATE_OBJECT_DIRECTORIES
	A colon (semicolon on Windows) separated list of object directories
	to search for objects.

In addition to these we support the core.worktree config setting when
the git directory is set deliberately instead of being found.

Change-Id: I2b9bceb13c0f66b25e9e3cefd2e01534a286e04c
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Change-Id: Iec0688232bd59d4626111d77633109918e8e1df3
Signed-off-by: Mykola Nikishov <mn@mn.com.ua>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>

Change-Id: I4e369382b8a83a5c0772462d1b176b1e23910ada

If we are on a Java 6 JVM we should have the Console class available,
unless the user has redirected /dev/null to stdin.  When there is a
console present we would prefer to use that for command line prompts
as that is what the user expects from a command line tool.

Change-Id: Ibaf87bb5540371d94d96d1b7e94ca002f752e5bd
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

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>

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>

Since we are now using the maven-shade-plugin to flatten out our
dependencies into a single stand-alone JAR we no longer need to
use our own command line utility.

Change-Id: I057c782cc66c44f11ed2ff2b4b4ca9cc82c7426a
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

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>

This way we depend upon the MANIFEST.MF to define our classpath
and our build will act more like any other OSGI bundle build.

Change-Id: I9e1f1f5a0bccb0ab0e39e49b75fb400fea446619
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

This code belongs inside of the org.eclipse.jgit.pgm bundle
so it is executable from the command line.

In af5cb5ced938 ("Move AmazonS3 command line utility to jgit-pgm")
I accidentally moved this class into the wrong directory, probably
during some sort of rebase when I tried to pull this commit out of
its original position in an abanonded Maven refactoring series.

Change-Id: I19adafa87b70586dd44040e9dfce30f3d482ed28
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

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>

Our project coding conventions do not want trailing whitespace at
the end of a source code line.  Configure Eclipse to automatically
remove them when saving any Java source file.

Change-Id: I9701366b3b1240879761b30556e6ff416e969e1d
Reviewed-by: Mykola Nikishov <mn@mn.com.ua>
Reviewed-by: Alex Blewitt <alex.blewitt@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

As discussed on the egit-dev mailing list, we prefer not to have
trailing whitespace in our source code.  Correct all currently
offending lines by trimming them.

Change-Id: I002b1d1980071084c0bc53242c8f5900970e6845
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

All 3rd party dependencies must come from orbit to comply
with Eclipse development process.

Change-Id: Ia43892ab6d0169f8335c1a41b37e8c12e94cafe2
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

My Galileo eclipse was complaining about unneeded import statements and
how static methods have been accessed in Diff.java. There was also one method
call which could be removed because he had no sideeffects and the return value
was not used. I fixed this so that there are no warnings anymore.

Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Change-Id: I48d7e01536aab1524140d72af574e3fd7149cd23

This commit contains fixes provided by Christian Halstrick.

Bug: 291083
Eclipse-CQ: 3559
Change-Id: If8d187e70a51f31040f99098489e513791dc6415
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

This is the last chunk of code in jgit-core which references the awtui
package.  Moving it to the only consumer in jgit-pgm allows us to move
the awtui package over to the jgit-awtui module.

Change-Id: I2fd81be2076117b2f2c5f8ed45de7f29272af6cf
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

This removes one of the few remaining dependencies on AWTAuthenticator
from the core library.  For the most part the interface is identical to
the prior main method.  The jgit-pgm Main class already sets up the
HTTP proxy and authenticator for us, so we don't need to do that in
our new run method.

Change-Id: Ia2cce34d34c97b88214a8bd8f2cc542845e19032
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

We now supply an exported format description for anyone to import
into their own workbench, and all projects reference this style in
a consistent way.

Change-Id: Ic243544a761ef2db29025a89ba6bb932a3a3ce34
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Per CQ 3448 this is the initial contribution of the JGit project
to eclipse.org.  It is derived from the historical JGit repository
at commit 3a2dd9921c8a08740a9e02c421469e5b1a9e47cb.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>