git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Rast <tr@thomasrast.ch>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Shawn Pearce <spearce@spearce.org>
Subject: Re: Git GSoC 2014
Date: Thu, 13 Feb 2014 22:45:01 +0100	[thread overview]
Message-ID: <87bnya8z6q.fsf@thomasrast.ch> (raw)
In-Reply-To: <20140213091037.GA28927@sigill.intra.peff.net> (Jeff King's message of "Thu, 13 Feb 2014 04:10:37 -0500")

Jeff King <peff@peff.net> writes:

>   - somebody to be the backup admin (I am assuming I'll be the primary
>     admin, but as always, if somebody else wants to...)

I can be backup, if Shawn doesn't want it.

>   - ideas ideas ideas

Here's my moonshot:

--- 8< ---
Replace object loading/writing layer by libgit2

Git reads objects from storage (loose and packed) through functions in
sha1_file.c.  Most commands only require very simple, opaque read and
write access to the object storage.  As a weatherballoon, show that it
is feasible to use libgit2 git_odb_* routines for these simple callers.

Aim for passing the git test suite using git_odb_* object storage
access, except for tests that verify behavior in the face of storage
corruption, replacement objects, alternate storage locations, and
similar quirks.  Of course it is even better if you pass the test suite
without exception.

Language: C
Difficulty: hard
Possible mentors: Thomas Rast and <fill in libgit2 expert>
--- >8 ---

That absolutely requires a co-mentor from the libgit2 side to do,
however.  Perhaps you could talk someone into it? ;-)

Motivation: I believe that migrating to libgit2 is the better approach,
medium term, than rewriting everything ourselves to be nice, clean and
thread-safe.  I took a shot a while ago at making the pack reading code
thread-safe, but it's adding mess when we could simply replace it all by
the already thread-safe libgit2 calls.  It also helps shake out
incompatibilities in libgit2.

Downside: not listing "code merged" as a goal may not make the project
as shiny, neither for Git nor for the student.

-- 
Thomas Rast
tr@thomasrast.ch

  reply	other threads:[~2014-02-13 21:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-13  9:10 Git GSoC 2014 Jeff King
2014-02-13 21:45 ` Thomas Rast [this message]
2014-02-13 22:50   ` Junio C Hamano
2014-02-14  7:26     ` Thomas Rast
2014-02-14  9:44   ` David Kastrup
2014-02-15 12:17     ` Thomas Rast
2014-02-15 12:35       ` Duy Nguyen
2014-02-15 13:03       ` David Kastrup
2014-02-15 23:47       ` Shawn Pearce
2014-02-14 17:53   ` Vicent Martí
2014-02-13 23:17 ` Ramkumar Ramachandra
2014-02-14 10:41   ` Jeff King
2014-02-14 15:30     ` Ramkumar Ramachandra
2014-02-14 17:29       ` Jeff King
2014-02-14 18:56 ` Jeff King

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bnya8z6q.fsf@thomasrast.ch \
    --to=tr@thomasrast.ch \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=spearce@spearce.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.
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 NNTP newsgroup(s).