Re: Google Summer of Code 2008

From: Jakub Narebski <jnareb@gmail.com>
Date: Mar 1, 2008, 23:53 UTC
Message-ID: <200803020053.09815.jnareb@gmail.com>
In-Reply-To: <200802291304.16026.jnareb@gmail.com>

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