You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
50 lines
2.0 KiB
50 lines
2.0 KiB
15 years ago
|
= 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''
|