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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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
