Author | SHA1 | Message | Date |
---|---|---|---|
Christian Halstrick | b9ab040b45 |
Added MERGING_RESOLVED repository state
The repository state tells in which state the repo is and also which actions are currently allowed. The state MERGING is telling that a commit is not possible. But this is only true in the case of unmerged paths in the index. When we are merging but have resolved all conflicts then we are in a special state: We are still merging (means the next commit should have multiple parents) but a commit is now allowed. Since the MERGING state "canCommit()" cannot be enhanced to return true/false based on the index state (MERGING is an enum value which does not have a reference to the repository its state it is representing) I had to introduce a new state MERGING_RESOLVED. This new state will report that a commit is possible. CAUTION: there might be the chance that users of jgit previously blindly did a plain commit (with only one parent) when the RepositoryState allowed them to do so. With this change these users will now be confronted with a RepositoryState which says a commit is possible but before they can commit they'll have to check the MERGE_MESSAGE and MERGE_HEAD files and use the info from these files. Change-Id: I0a885e2fe8c85049fb23722351ab89cf2c81a431 Signed-off-by: Christian Halstrick <christian.halstrick@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> |
14 years ago |
Jens Baumgart | cc905e7d4b |
Make Repository.getConfig aware of changed config
In the current implementation Repository reads user and repository config only at creation point of time. The new implementatiopn checks in Repository.getConfig if user or repository config have changed on disk and reload the config if required. Change-Id: Ibd97515919ef66c6f8aa1a4fe8a11a6711335dad Signed-off-by: Jens Baumgart <jens.baumgart@sap.com> |
14 years ago |
Robin Rosenberg | 23827fefc0 |
Intermediate workaround for JGit's lack of core.autocrlf support
Windows users by default have core.autocrlf set to true. JGit does not recognize the flags and thus works as if it is set. In order to make JGit more compatible with msysgit we set the flag to false in repositories that JGit creates. Bug: 301775 Change-Id: I7ea462fe3516e5060b87aa1f7ed63689936830c2 Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> |
14 years ago |
Shawn O. Pearce | 73b6efc928 |
Replace writeSymref with RefUpdate.link
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> |
14 years ago |
Shawn O. Pearce | 01b5392cdb |
Rewrite reference handling to be abstract and accurate
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> |
14 years ago |
Robin Rosenberg | 0b8b6b5309 |
Introduce a named constant for the .git directory.
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> |
14 years ago |
Robin Rosenberg | aa4b115791 |
Read core.worktree regardless of whether .git was discovered or not
The C Git documentation stated that the core.worktree config was not read when the .git directory was found implicitly (from the working directory). This was not true, and had not been so for a long time. The documentation has been updated to document the existing behaviour. Change-Id: If1e81b6a981b9d70e849f24872f01c110e9bc950 Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> |
14 years ago |
Robin Rosenberg | eb63bfc1b8 |
Recognize Git repository environment variables
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> |
14 years ago |
Robin Rosenberg | 5b13adcea9 |
Add support for creating detached heads
An extra flag when creating a RefUpdate object allows the caller to destroy the symref and replace it with an object ref, a.k.a. detached HEAD. Change-Id: Ia88d48eab1eb4861ebfa39e3be9258c3824a19db Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> |
14 years ago |
Sasa Zivkov | 99ab22c474 |
Don't create .git/remotes folders on init
For historical reasons JGit was creating .git/remotes folder when
initialization an empty repository. However, this folder is never
used and the new Git repository format doesn't contain them.
Removed the unnecessary remotes folder creation, it was removed from
C Git in
|
14 years ago |
Alex Blewitt | 4d91645e89 |
Remove trailing whitespace at end of line
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> |
14 years ago |
Christian Halstrick | ffc8b42957 |
Add support for logAllRefUpdates configuration parameter
Honor the configuration parameter core.logAllRefUpdates when writing reflogs. Instead of writing reflog entries always only write reflogs if this parameter is set to true or if the corresponding file in the <git-dir>/logs directory already exists. In other words: if you are updating a ref and this parameter is set to false and there is no file corresponding to your ref in the <git-dir>/logs folder then no reflog will be written. This is a fix for the issue http://code.google.com/p/egit/issues/detail?id=4 Change-Id: I908e4c77e3630dc3223b2d2a47cb4534dbe4ed42 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Christian Halstrick <christian.halstrick@sap.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> |
14 years ago |
Git Development Community | 1a6964c827 |
Initial JGit contribution to eclipse.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
|
14 years ago |