TODO

   1 = Eclipse Plugin Wishlist =
   2
   3 Now that we have some basic features in the Eclipse plugin, we need
   4 to focus on making it usable by average users doing daily tasks.
   5
   6 == Commit ==
   7
   8 Commit all (or selected) files to current branch.
   9
  10 This feature is trivial if the repository is fully mounted within
  11 Eclipse, as Eclipse has the entire working tree available, making
  12 it easy to write out the blobs and tree objects needed to form the
  13 root tree for the new commit.
  14
  15 Its less easy when the repository is not fully mounted within
  16 Eclipse.  (See for example the egit repository itself; the
  17 repository has 3 projects in it so Eclipse doesn't see the top
  18 level directory.)  In this case egit needs to preseve the files
  19 that are currently either in HEAD or in the index for the parts
  20 of the tree it cannot see, while using the files it has in memory
  21 for the parts of the tree that it can see.  In this latter case I'm
  22 thinking that preserving HEAD rather than the index is the right way
  23 to go here, as jgit does not play nicely with core Git's index file.
  24 Consequently users should be discouraged from trying to create a
  25 commit based on the results of both tools.
  26
  27 == Create Branch ==
  28
  29 Create a new branch from any revision specification.
  30
  31 == Delete Branch ==
  32
  33 Delete a branch.
  34
  35 == Switch Branch ==
  36
  37 Switch to an existing branch, updating the working directory to match.
  38
  39 Note that updating the working directory may require a 3 way merge
  40 if the working directory is dirty (git checkout -m).
  41
  42 My usual git working style is to not switch branches with a dirty
  43 working directory; I always commit to the current branch before
  44 switching to a new one. I mention that because I assume it'll be
  45 easier to implement that workflow first; once you have commit
  46 capability, you can do that style of branch switching (either
  47 preventing the switch or doing an implicit commit when the working
  48 directory is dirty) without having to worry about merging. ''--
  49 Steven Grimm''
  50
  51 == Fetch ==
  52
  53 Fetching changes from a remote repository into a tracking branch.
  54 Aka "git fetch".
  55
  56 I'd like to keep egit/jgit 100% pure Java, to make it easier to
  57 install the plugin on a wide varity of systems.  This means we
  58 need to implement a good amount of code for the network protocol
  59 and the --objects-edge feature of rev-list.  Although a lot to code
  60 its probably only slightly more effort than forking out to run git
  61 fetch and deal with its error conditions.
  62
  63 Fetching over SSH should be possible through the jsch library
  64 included in Eclipse; this is what CVS uses for its SSH2 connections.
  65 Fetching from a local directory should just be a matter of creating a
  66 Repository object on that directory path (no need to fork a process
  67 like core Git does).
  68
  69 Initially I'd like to stay away from the commit walkers (e.g. HTTP).
  70 Actually supporting them is likely a really good argument for at
  71 least making it possible for the user to configure jgit to invoke
  72 "git fetch" in an external process.
  73
  74 == Merge ==
  75
  76 Merging changes from one local branch to another.
  77
  78 Again, like fetch I'd like to keep egit/jgit 100% pure Java and
  79 implement merge-recursive in Java.  We may need to invoke RCS
  80 merge if Eclipse doesn't have its own 3 way file merge algorithm
  81 available, or do what core Git just did and implement a 3 way in
  82 memory merge algorithm.  git-merge-recursive is only 1336 lines of C
  83 so it should not be too difficult to port the algorithm to pure Java.
  84
  85 == Push ==
  86
  87 Pushing changes to a remote repository.
  88
  89 A lot like fetch, we should be able to support the native Git
  90 protocol for SSH based push, and for local directory access we just
  91 need to mount the other repository as a new Repository object and
  92 copy the object data from one to the other.  Probably easier than
  93 it is for core Git.
  94
  95 As far as packing data over the network goes I don't want to
  96 implement the binary delta algorithm in pure Java right now.  So this
  97 means we would send packs containing only whole objects (no deltas).
  98 This shouldn't really be an issue for the receiving end, except
  99 that we will have a slightly higher network transfer cost coming
 100 from egit than if core Git was used to push the same set of objects.
 101
 102 == Graphical History Viewer ==
 103
 104 A graphical history viewer similar to gitk or qgit, but in SWT/JFace
 105 so it can run within the Eclipse workbench.
 106
 107 == SVN Integration ==
 108
 109 It would be swell -- but put it at the bottom of your priority list
 110 -- to have git-svn interoperability; sadly most of my git usage at
 111 the moment is in cloned svn repositories and it would be great if
 112 egit could do the right thing when the current git repo is cloned
 113 from svn. What "the right thing" is, exactly, is debatable, but I
 114 suppose some kind of integration with the Subclipse plugin is one
 115 possibility (and if nothing else, that plugin probably has code
 116 that can be reused.) I'd like to be able to update from and commit
 117 to the parent svn repository. ''-- Steven Grimm''
 118
 119 I'm considering this to be out of scope for the time being, but if
 120 someone takes it on and submits reasonable patches we'll include
 121 them. ''-- Shawn Pearce''