Re: [GSoC] Google Summer of Code 2009 - new ideas

[P Baker <me@retrodict.com>]

I posted to this list serve a few days ago about one of the 2008 SoC
ideas. Are those ideas still plausible? Specifically, I'm interested
in pursuing the git-submodule update. Is this off the drawing board?

P Baker

On 3/6/09, Jakub Narebski <jnareb@gmail.com> wrote:
> Time to submit application as mentoring organization to
>  Google Summer of Code 2009 is close:  March 9 -- March 13.
>
>  I'd like to add a few ideas to SoC2009Ideas wiki page, but before I do
>  this I'd like to ask for comments.  (The proposals also lacks proposed
>  mentor).
>
>  I am wondering if it would be worth it to make a separate class between
>  "New to Git?" easy tasks, and "Larger Projects" hard tasks...
>
>  BTW. some of ideas didn't make it from SoC2008Ideas wiki page to current
>  year page, namely:
>   * Apply sparse To Fix Errors
>   * Lazy clone / remote alternates
>   * Implement git-submodule using .gitlink file
>   * Teach git-apply the 3-way merge fallback git-am knows
>   * Better Emacs integration
>  Was this ommision deliberate or accidental?
>
>
>  -- >8 --
>
>  = New To Git? New To Open Source Development? =
>
>  == Packfile caching for git-daemon ==
>
>  Even with delta reuse, enumerating objects to be present in packfile
>  generates significant load on server for pack-generating protocols,
>  such as git:// protocol used by git-daemon.  Many of requests result in
>  the same packfile to be generated and sent; examples include full
>  clone, or fetch of all branches since last update.  It would make sense
>  then to save (cache) packfiles, and if possible avoid regenerating
>  packfiles by sending them from cache.  (Possible extension would be to
>  send slightly larger pack than needed if one can reuse cached packfile
>  instead).
>
>  The goal is for git-daemon to cache packfiles, use cached packfiles if
>  possible, and to manage packfile cache.  Note that one would need in
>  the final version some way to specify upper limit on packfile cache
>  size and some cache entry expire policy.
>
>  '''Goal:''' Support for packfile cache in git-daemon,
>             benchmark server load
>  '''Language:''' C
>
>  == Single credentials ==
>
>  Currently if you don't save your username and password in plain-text
>  `.netrc` file (for HTTP transport), or avoid need for interactive
>  credentials using public key / private key pair (for SSH), you need to
>  repeat credentials many times during single git-fetch or git-clone
>  command.  The goal is to reuse existing connections if possible, so the
>  whole transaction occurs using single connection and single
>  credentials; if that is not possible cache credentials (in secure way)
>  so user need to provide username and password at most once.
>
>  '''Goal:''' git-fetch and git-clone over HTTPS and git://
>             requiring providing username and password at most once
>  '''Language:''' C (perhaps also shell script)
>
>
>  = Larger Projects =
>
>  == Directory renames ==
>
>  Git deals quite well with renames when merging.  One of the corner cases
>  is when one side renamed some directory, and other side created ''new
>  files'' in the old-name directory.  Git currently creates new files in
>  resurrected old-name directory, while it could create new files under
>  new-name directory instead.
>
>  There is a bit of controversy about this feature, as for example in
>  some programming languages (e.g. Java) or in some project build tool
>  info it is not posible to simply move a file (or create new file in
>  different directory) without changing file contents.  Some say that
>  is better to fail than to do wrongly clean merge.
>
>  '''Goal:''' At minimum option enabling wholesame directory rename
>  detection.  Preferred to add dealing with directory renames also to
>  merge.  At last, one can try to implement "git log --follow" for
>  directories.
>  '''Language:''' C
>  '''See:''' [http://thread.gmane.org/gmane.comp.version-control.git/99529
>  |RFC PATCH v2 0/2| Detection of directory renames] thread on git
>  mailing list (via GMane)
>  '''See also:'''
>   *
>  [http://thread.gmane.org/gmane.comp.version-control.git/80912/focus=81362
>  merge renamed files/directories?] subthread on git mailing list
>   * [http://thread.gmane.org/gmane.comp.version-control.git/108106
>  Comments on "Understanding Version Control" by Eric S. Raymond] thread
>  contains some thoughts on wholesame directory rename detection
>   * [http://blog.teksol.info/2008/01/16/directory-renames-under-git
>  Directory renames under Git] blog post notice the issue
>   * [http://www.markshuttleworth.com/archives/123 Renaming is the killer
>  app of distributed version control] blog post by Mak Shuttleworth
>  (pro-Bazaar).
>
>  --
>  Jakub Narebski
>  Poland
>
> --
>  To unsubscribe from this list: send the line "unsubscribe git" in
>  the body of a message to majordomo@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>