[JGIT PATCH 0/6] Misc. documentation cleanups

[JGIT PATCH 0/6] Misc. documentation cleanups

[Shawn O. Pearce]

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%)

[JGIT PATCH 1/6] Updated egit INSTALL document to mention Eclipse 3.4.0

[Shawn O. Pearce]

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 <spearce@spearce.org>
---
 INSTALL |    2 +-
 README  |    3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/INSTALL b/INSTALL
index bb303c1..76be0a4 100644
--- a/INSTALL
+++ b/INSTALL
@@ -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
diff --git a/README b/README
index af601e8..a10b8d4 100644
--- a/README
+++ b/README
@@ -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
-- 
1.6.0.rc1.250.g9b5e2

[JGIT PATCH 2/6] Rename INSTALL to EGIT_INSTALL

[Shawn O. Pearce]

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 <spearce@spearce.org>
---
 INSTALL => EGIT_INSTALL |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
 rename INSTALL => EGIT_INSTALL (98%)

diff --git a/INSTALL b/EGIT_INSTALL
similarity index 98%
rename from INSTALL
rename to EGIT_INSTALL
index 76be0a4..142526a 100644
--- a/INSTALL
+++ b/EGIT_INSTALL
@@ -1,5 +1,5 @@
 
-	EGit/JGit installation
+	EGit Installation
 
 PREREQUISITES
 
-- 
1.6.0.rc1.250.g9b5e2

[JGIT PATCH 3/6] Mark completed items (commit, fetch, push, graphic log) in TODO file

[Shawn O. Pearce]

These are done and don't need to be mentioned anymore.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 README |    3 --
 TODO   |   66 ----------------------------------------------------------------
 2 files changed, 0 insertions(+), 69 deletions(-)

diff --git a/README b/README
index a10b8d4..db11c25 100644
--- a/README
+++ b/README
@@ -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.
diff --git a/TODO b/TODO
index a7ef2b9..5f35b25 100644
--- a/TODO
+++ b/TODO
@@ -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
-- 
1.6.0.rc1.250.g9b5e2

[JGIT PATCH 4/6] Remove outdated warnings from the README

[Shawn O. Pearce]

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 <spearce@spearce.org>
---
 README |   13 -------------
 1 files changed, 0 insertions(+), 13 deletions(-)

diff --git a/README b/README
index db11c25..e18a9eb 100644
--- a/README
+++ b/README
@@ -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.
-- 
1.6.0.rc1.250.g9b5e2

[JGIT PATCH 5/6] Remove the "jgit is slow" remark from README

[Shawn O. Pearce]

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 <spearce@spearce.org>
---
 README |   30 ------------------------------
 1 files changed, 0 insertions(+), 30 deletions(-)

diff --git a/README b/README
index e18a9eb..334f3d5 100644
--- a/README
+++ b/README
@@ -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.
-- 
1.6.0.rc1.250.g9b5e2

[JGIT PATCH 6/6] Remove the "windows isn't supported" remark from README

[Shawn O. Pearce]

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 <spearce@spearce.org>
---
 README |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/README b/README
index 334f3d5..dd4a910 100644
--- a/README
+++ b/README
@@ -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.
-- 
1.6.0.rc1.250.g9b5e2