Remove TODO file and move to bugzilla

There is no longer any value in keeping track of things we need to
implement in a file in the top level of the source code.  Time has
proven we don't keep it current, as some of these features are
already implemented, and some are still being worked on.

Worse, many of these items were for the EGit plugin, which has no
relationship to JGit.

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

diff --git a/TODO b/TODO
deleted file mode 100644 (file)
index c4ce95e..0000000
--- a/TODO
+++ /dev/null
@@ -1,49 +0,0 @@
-= JGit Wishlist =
-
-Below are some of the areas that needs work. Also take a look at JGit
-related issues in the EGit project:
-
- - http://code.google.com/p/egit/issues/list?q=label:Component-JGit
-
-== Switch Branch ==
-
-Switch to an existing branch, updating the working directory to match.
-
-Note that updating the working directory may require a 3 way merge
-if the working directory is dirty (git checkout -m).
-
-My usual git working style is to not switch branches with a dirty
-working directory; I always commit to the current branch before
-switching to a new one. I mention that because I assume it'll be
-easier to implement that workflow first; once you have commit
-capability, you can do that style of branch switching (either
-preventing the switch or doing an implicit commit when the working
-directory is dirty) without having to worry about merging. ''--
-Steven Grimm''
-
-== Merge ==
-
-Merging changes from one local branch to another.
-
-Again, like fetch I'd like to keep egit/jgit 100% pure Java and
-implement merge-recursive in Java.  We may need to invoke RCS
-merge if Eclipse doesn't have its own 3 way file merge algorithm
-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.
-
-== SVN Integration ==
-
-It would be swell -- but put it at the bottom of your priority list
--- to have git-svn interoperability; sadly most of my git usage at
-the moment is in cloned svn repositories and it would be great if
-egit could do the right thing when the current git repo is cloned
-from svn. What "the right thing" is, exactly, is debatable, but I
-suppose some kind of integration with the Subclipse plugin is one
-possibility (and if nothing else, that plugin probably has code
-that can be reused.) I'd like to be able to update from and commit
-to the parent svn repository. ''-- Steven Grimm''
-
-I'm considering this to be out of scope for the time being, but if
-someone takes it on and submits reasonable patches we'll include
-them. ''-- Shawn Pearce''