From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:06
After the JavaGit announcement today it was pointed out to me that
our top-level documentation in egit.git is not accurate with our
current project state.
This is a first attempt at getting things current. Its likely not
complete and we should do more before we ship the next release.
Shawn O. Pearce (6):
Updated egit INSTALL document to mention Eclipse 3.4.0
Rename INSTALL to EGIT_INSTALL
Mark completed items (commit, fetch, push, graphic log) in TODO file
Remove outdated warnings from the README
Remove the "jgit is slow" remark from README
Remove the "windows isn't supported" remark from README
INSTALL => EGIT_INSTALL | 4 +-
README | 53 +-------------------------------------
TODO | 66 -----------------------------------------------
3 files changed, 3 insertions(+), 120 deletions(-)
rename INSTALL => EGIT_INSTALL (96%)
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:06
Eclipse 3.4.0 is now final. Also we require at least 3.3.1, but
we really prefer 3.4.0.
Signed-off-by: Shawn O. Pearce <redacted>
---
INSTALL | 2 +-
README | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
@@ -6,7 +6,7 @@ PREREQUISITES In order to install the Git Eclipse plugin you need to have the following things.-- Eclipse version 3.2.1 or later (works up to 3.4 M1).+- Eclipse version 3.3.1, or 3.4.0 - Java 6. Java 1.5.0_11 and later seems to work. The reason is that the garbage collection does not do a good enough job when using memory
@@ -94,8 +94,7 @@ three for packaging. == COMPATIBILITY ==-- Eclipse 3.2.1 is the minimum Eclipse version. Expect this to change- in future versions.+- Eclipse 3.3.1 is the minimum Eclipse version, 3.4 is preferred. - Newer version of EGit/JGit may implement new functionality, remove existing functions and change others without other notice than what
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:06
This document is entirely about how to install the EGit plugins
and has nothing to do with JGit itself. Later if/when we split the
Git repository into two trees (one for jgit, one for egit) we can
rename this back to just plain INSTALL inside of the EGit repository.
Signed-off-by: Shawn O. Pearce <redacted>
---
INSTALL => EGIT_INSTALL | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
rename INSTALL => EGIT_INSTALL (98%)
diff --git a/INSTALL b/EGIT_INSTALLsimilarity index 98%rename from INSTALLrename to EGIT_INSTALLindex 76be0a4..142526a 100644--- a/INSTALL+++ b/EGIT_INSTALL
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:06
These are done and don't need to be mentioned anymore.
Signed-off-by: Shawn O. Pearce <redacted>
---
README | 3 --
TODO | 66 ----------------------------------------------------------------
2 files changed, 0 insertions(+), 69 deletions(-)
@@ -177,9 +177,6 @@ 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.-- GIT network protocol to pull objects from a remote repository or- push objects to a remote repository.- - Merging. - Repacking from within the plugin.
@@ -3,27 +3,6 @@ Now that we have some basic features in the Eclipse plugin, we need to focus on making it usable by average users doing daily tasks.-== Commit ==--Commit all (or selected) files to current branch.--This feature is trivial if the repository is fully mounted within-Eclipse, as Eclipse has the entire working tree available, making-it easy to write out the blobs and tree objects needed to form the-root tree for the new commit.--Its less easy when the repository is not fully mounted within-Eclipse. (See for example the egit repository itself; the-repository has 3 projects in it so Eclipse doesn't see the top-level directory.) In this case egit needs to preseve the files-that are currently either in HEAD or in the index for the parts-of the tree it cannot see, while using the files it has in memory-for the parts of the tree that it can see. In this latter case I'm-thinking that preserving HEAD rather than the index is the right way-to go here, as jgit does not play nicely with core Git's index file.-Consequently users should be discouraged from trying to create a-commit based on the results of both tools.- == Create Branch == Create a new branch from any revision specification.
@@ -48,29 +27,6 @@ preventing the switch or doing an implicit commit when the working directory is dirty) without having to worry about merging. ''-- Steven Grimm''-== Fetch ==--Fetching changes from a remote repository into a tracking branch.-Aka "git fetch".--I'd like to keep egit/jgit 100% pure Java, to make it easier to-install the plugin on a wide varity of systems. This means we-need to implement a good amount of code for the network protocol-and the --objects-edge feature of rev-list. Although a lot to code-its probably only slightly more effort than forking out to run git-fetch and deal with its error conditions.--Fetching over SSH should be possible through the jsch library-included in Eclipse; this is what CVS uses for its SSH2 connections.-Fetching from a local directory should just be a matter of creating a-Repository object on that directory path (no need to fork a process-like core Git does).--Initially I'd like to stay away from the commit walkers (e.g. HTTP).-Actually supporting them is likely a really good argument for at-least making it possible for the user to configure jgit to invoke-"git fetch" in an external process.- == Merge == Merging changes from one local branch to another.
@@ -82,28 +38,6 @@ available, or do what core Git just did and implement a 3 way in memory merge algorithm. git-merge-recursive is only 1336 lines of C so it should not be too difficult to port the algorithm to pure Java.-== Push ==--Pushing changes to a remote repository.--A lot like fetch, we should be able to support the native Git-protocol for SSH based push, and for local directory access we just-need to mount the other repository as a new Repository object and-copy the object data from one to the other. Probably easier than-it is for core Git.--As far as packing data over the network goes I don't want to-implement the binary delta algorithm in pure Java right now. So this-means we would send packs containing only whole objects (no deltas).-This shouldn't really be an issue for the receiving end, except-that we will have a slightly higher network transfer cost coming-from egit than if core Git was used to push the same set of objects.--== Graphical History Viewer ==--A graphical history viewer similar to gitk or qgit, but in SWT/JFace-so it can run within the Eclipse workbench.- == SVN Integration == It would be swell -- but put it at the bottom of your priority list
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:06
The Windows support has come a long way since this was written
into the README. We actually (mostly) support repositories that
were created on Cygwin, even if they used --shared to setup object
alternates with Cygwin paths, and we honor the user's Cygwin home
directory for configuration and SSH keys. Windows is about as well
supported as one can get on Java.
Signed-off-by: Shawn O. Pearce <redacted>
---
README | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
@@ -174,10 +174,6 @@ partial files simple. - Documentation. :-)-- Windows support is new and very ligthly tested. Do not blame us if- it blows, but tell us about it and what you did. Double check- everything.- - gitattributes support In particular CRLF conversion is not implemented. Files are treated as byte sequences.
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:06
Historically this may have been true, back when we built things
on the lib.Commit and lib.Tree API. Those APIs are quickly being
rebuilt around RevWalk and TreeWalk, which are much more powerful
and significantly faster.
Most testing indicates that once the JIT has had a chance to do
its optimization magic on the jgit library we get performance that
really does rival C git running on the same system. Since C git
is so ridiculously fast we're probably still beating many of the
other VCS tools available.
Signed-off-by: Shawn O. Pearce <redacted>
---
README | 30 ------------------------------
1 files changed, 0 insertions(+), 30 deletions(-)
@@ -188,36 +188,6 @@ partial files simple. - The Eclipse plugin cannot handle files outside any Eclipse project. You need commit changes to such files outside of Eclipse.-- Speed in some areas-- Java is "slooow", they say. Not true as a general statement. A lot of Java- code is slow because it it not optimized (to some extent due to this- belief). Java has quite good performance although it cannot compete with- C code written by good hackers simply because C can be optimized more than- Java when you actually do it and have the skills to do it. Some areas of- the plugin have been optimized but not all and not conclusively. In general- however Java almost always needs more memory than an application written in - e.g. C. In particular there is an overhead from the rather large standard- libraries that a normal Java installation comes with. See the ACM report:-- Prechelt, L. 1999. Technical opinion: comparing Java vs. C/C++- efficiency differences to interpersonal differences. Commun. ACM 42, - 10 (Oct. 1999), 109-112. DOI= http://doi.acm.org/10.1145/317665.317683-- for an interesting comparison of C, C++ and Java. It is somewhat dated so - the comparison involved Java 1.2, i.e. without hotspot that appeared in Java - 1.3 and the shared runtime in 1.4. Those features made common Java- applications many times faster than with Java 1.2-- The conclusion from having about 30 programmers write a program to the same- specification using their own choice of language (from C,C++ and Java) is- that the skills of the programmer is what determines the performance of the- code rather than choice of programming language.-- JGit is much slower (measured up to eight times for some random cases), but- then the real Git is ridicilously fast.-- == Support == Post question, comments or patches to the git@vger.kernel.org mailing list.
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:06
We no longer fear the jgit library eating a repository, or causing
other sorts of corruption. Nor do we fear the Eclipse plugin
locking up your workbench, as it just has never happened.
Signed-off-by: Shawn O. Pearce <redacted>
---
README | 13 -------------
1 files changed, 0 insertions(+), 13 deletions(-)
@@ -66,15 +66,6 @@ three for packaging. == WARNINGS / CAVEATS ==-- The plugin could lockup your Eclipse workbench. I've tried to- make it stable and function in such a way that it can't crash- the workbench, but that doesn't mean it won't. :-)--- This package might eat your files. Everything I've added to a- repository with it has unpacked properly both with itself and- with the canonical C based implementation, but that doesn't mean- it won't generate a corrupt object.- - Symbolic links are not supported because java does not support it. Such links could be damaged.
@@ -88,10 +79,6 @@ three for packaging. have no information about other vendors. Please report your findings if you try.-- Do not trust this plugin to always do the right thing (yet). Please- check with the real Git and report any problems.-- == COMPATIBILITY == - Eclipse 3.3.1 is the minimum Eclipse version, 3.4 is preferred.