On Fri, 29 Feb 2008, Jakub Narebski wrote: > I'd send other ideas (including new ones, like translating > svn:externals into git submodules in git-svn; or making git mode > for Emacs have all features of tig, git-gui and gitk; or improving > shallow clone support) in a later post. And here they are. * GNU Emacs git GUI Make git mode for Emacs full featured git GUI, and not only commit tool, following ideas of PCL-CVS... and its limitation. I guess that DVC (http://download.gna.org/dvc) git mode is one thing to examine searching for features to implement, but from what I have read in documentation it is quite a but GNU Arch centric. Other git GUIs, like git-gui, gitk, qgit, tig could also be inspiration for features. Goal: Allow creating and switching branches, examining history, merging, fetching etc. from withing Emacs. Should include modes for git config file forma and format-patch patches. Language: Emacs Lisp Suggested mentors: Alexandre Julliard David Kagedal * git-svn and submodules (and other improvements) Make git-svn translate svn:externals (full kind) submodules into git submodules. This might require improvements to submodule support in git. Other improvements include proper dealing with miscelaneus Subversion properties (translating them into .gitignore and .gitattributes entries). Goal: Succesfull two-way interaction with Subversion repository using svn: externals for submodules. Language: Perl Suggested mentors: Eric Wong (git-svn author) Shawn O. Pearce Johannes Schindelin * Shallow clone improvements IIRC the interaction with shallow clone is a bit limited. Lift those limitations, allowing for example to push from shallow to full clone. Goal: Push from shallow clone to full clone, or other shallow clone. Language: C Suggested mentors: Johannes Schindelin * blame Merge Strategy A new merge strategy "merge-blame". It should take advantage of code (fragment) movement and copying detection in git blame, correctly applying change to correct place if code was moved (e.g. reorganizing code) or moving fragment into another file. This strategy should probably be a function within merge-recursive that is activated only when merge-recursive is invoked as merge-blame (or some perhaps some better name). Further it probably should only be used when a file fails to be merged cleanly, as a "last resort before asking the developer to do it for me" sort of trick. Rationale here is the blame computation is non-trivial and will take some CPU time, so we want to avoid that in the common cases of non-moved code. Goal: Demonstrate a working merge-blame that can fairly accurately merge changes made to moved code segments. Language: probably C Suggested mentors: unknown -- Jakub Narebski -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html