From: Jakub Narebski <jnareb@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: "Shawn O. Pearce" <spearce@spearce.org>,
Robin Rosenberg <robin.rosenberg.lists@dewire.com>,
git@vger.kernel.org, John Hawley <warthog9@kernel.org>
Subject: Re: Google Summer of Code 2008
Date: Sun, 2 Mar 2008 00:53:08 +0100 [thread overview]
Message-ID: <200803020053.09815.jnareb@gmail.com> (raw)
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
next prev parent reply other threads:[~2008-03-01 23:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-26 22:56 Google Summer of Code 2008 Jakub Narebski
2008-02-26 23:39 ` Johannes Schindelin
2008-02-28 6:36 ` Shawn O. Pearce
2008-02-28 7:03 ` Jeremy Maitin-Shepard
2008-02-28 10:27 ` Johannes Schindelin
2008-02-28 10:27 ` Johannes Schindelin
2008-02-29 12:04 ` Jakub Narebski
2008-02-29 12:47 ` Julian Phillips
2008-02-29 13:03 ` Johannes Schindelin
2008-03-01 1:37 ` Julian Phillips
2008-03-01 0:31 ` Sam Vilain
2008-03-01 1:03 ` Johannes Schindelin
2008-03-01 5:07 ` Sam Vilain
2008-03-01 23:53 ` Jakub Narebski [this message]
2008-03-02 16:05 ` Matthieu Moy
2008-03-02 16:46 ` Jakub Narebski
2008-03-02 18:05 ` Matthieu Moy
2008-03-02 23:04 ` Martin Langhoff
2008-03-02 23:35 ` Johannes Schindelin
2008-02-28 13:59 ` Jonas Fonseca
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200803020053.09815.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=robin.rosenberg.lists@dewire.com \
--cc=spearce@spearce.org \
--cc=warthog9@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).