01b5392cdb
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>
|
||
|---|---|---|
| org.eclipse.jgit | ||
| org.eclipse.jgit-feature | ||
| org.eclipse.jgit.console | ||
| org.eclipse.jgit.http.server | ||
| org.eclipse.jgit.http.test | ||
| org.eclipse.jgit.junit | ||
| org.eclipse.jgit.pgm | ||
| org.eclipse.jgit.test | ||
| org.eclipse.jgit.ui | ||
| tools | ||
| .gitattributes | ||
| LICENSE | ||
| README | ||
| SUBMITTING_PATCHES | ||
| pom.xml | ||
README
== Java GIT ==
This package is licensed under the BSD.
org.eclipse.jgit/
A pure Java library capable of being run standalone, with no
additional support libraries. Some JUnit tests are provided
to exercise the library. The library provides functions to
read and write a GIT formatted repository.
All portions of jgit are covered by the BSD. Absolutely no GPL,
LGPL or EPL contributions are accepted within this package.
org.eclipse.jgit.test/
Unit tests for org.eclipse.jgit and the same licensing rules.
== WARNINGS / CAVEATS ==
- Symbolic links are not supported because java does not support it.
Such links could be damaged.
- Only the timestamp of the index is used by jgit check if the index
is dirty.
- Don't try the library with a JDK other than 1.6 (Java 6) unless you
are prepared to investigate problems yourself. JDK 1.5.0_11 and later
Java 5 versions *may* work. Earlier versions do not. JDK 1.4 is *not*
supported. Apple's Java 1.5.0_07 is reported to work acceptably. We
have no information about other vendors. Please report your findings
if you try.
- CRLF conversion is never performed. On Windows you should thereforc
make sure your projects and workspaces are configured to save files
with Unix (LF) line endings.
== Package Features ==
org.eclipse.jgit/
* Read loose and packed commits, trees, blobs, including
deltafied objects.
* Read objects from shared repositories
* Write loose commits, trees, blobs.
* Write blobs from local files or Java InputStreams.
* Read blobs as Java InputStreams.
* Copy trees to local directory, or local directory to a tree.
* Lazily loads objects as necessary.
* Read and write .git/config files.
* Create a new repository.
* Read and write refs, including walking through symrefs.
* Read, update and write the Git index.
* Checkout in dirty working directory if trivial.
* Walk the history from a given set of commits looking for commits
introducing changes in files under a specified path.
* Object transport
Fetch via ssh, git, http, Amazon S3 and bundles.
Push via ssh, git and Amazon S3. JGit does not yet deltify
the pushed packs so they may be a lot larger than C Git packs.
org.eclipse.jgit.pgm/
* Assorted set of command line utilities. Mostly for ad-hoc testing of jgit
log, glog, fetch etc.
== Missing Features ==
There are a lot of missing features. You need the real Git for this.
For some operations it may just be the preferred solution also. There
are not just a command line, there is e.g. git-gui that makes committing
partial files simple.
- Merging.
- Repacking.
- Generate a GIT format patch.
- Apply a GIT format patch.
- Documentation. :-)
- gitattributes support
In particular CRLF conversion is not implemented. Files are treated
as byte sequences.
- submodule support
Submodules are not supported or even recognized.
== Support ==
Post question, comments or patches to the git@vger.kernel.org mailing list.
== Contributing ==
See SUBMITTING_PATCHES in this directory. However, feedback and bug reports
are also contributions.
== About GIT ==
More information about GIT, its repository format, and the canonical
C based implementation can be obtained from the GIT websites:
http://git.or.cz/
http://www.kernel.org/pub/software/scm/git/
http://www.kernel.org/pub/software/scm/git/docs/