git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Motiejus Jakštys" <desired.mta@gmail.com>
To: git@vger.kernel.org
Subject: git2 cli (GSOC)
Date: Thu, 24 Mar 2011 02:02:32 +0000	[thread overview]
Message-ID: <20110324020232.GA10441@jakstys.lt> (raw)

Hello folks,

IMHO libgit2 is the best thing happening in Git world. Why? In world of
good software:

1) You implement a prototype of a thing (e83c516 probably)
2) See it's cool
3) Make it work and and all others start using it
4) Clean it up
5) Make it run on your watch.

libgit started git's way to (4). Note: I'm not saying git is "bad". It
has just hell too many dependencies for a watch.  When libgit2 and git2
are mature enough, it will run on Android and my watch.

There were some ideas in this mailing list about merging libgit2 to git
a couple of days ago. I think that's pointless, it should be the other
way around. Git features should get to libgit2 and git2.

Working is better than talking, so I created a git2 cli prototype[1]. It
has one feature, which is (should be?) equivalent to:
    $ git rev-list HEAD

You can run it like this:
    $ git2 rev-list <anything>

I created a very, very rough draft of git2.c. Thanks Jeff King for
advise[3] starting with a basic plumbing command. Those couple of hours
were quite interesting, because none of the human-readable API
documentation examples[4] I've tried actually worked. :)

We have some architecture questions to answer before getting started.
Are we aiming for a distributed 100s of executables architecture
(current git), or single huge binary (linux/busybox)? I would count for
single executable due to higher portability. However, plugging git2 for
git unit tests should require more thought.

Build configuration. Git-send-email is not really a must-have for an
embedded device, so we should be able to specify these features in
configure-time. How do you think it should be taken care of?
1) <buildtool> configure  --disable-everything --enable-email
2) make menuconfig and enjoy the blue screen of choice
3) ?

Build tool. I am not against waf (I've chosen waf for SoundPatty), I've
been using it, but it's too clumsy for me. Is it me that lacks
experience and it's a great tool, or am I not the only one who sometimes
feels confused and pissed off when trying to do some really simple
things? Should I stick to waf because libgit2 uses waf?

I want to do this hell a lot. I'm a student and I have C++
experience[2]. Actually I think it's not really my taste, since it is
too high-level for me. I love C and currently I am a full-time Python
web developer (django/friends)... I couldn't sleep for the last two
nights because libgit2 peaked my interest and my performance at work was
quite terrible. I see you are + for this tool as I am, so we might have
some great work together. Anyone would like to be a mentor?

About me.. I already told quite a lot, but you can find more info
(probably that means only CV) in my personal websites[5][6].

[1] https://github.com/Motiejus/git2/
[2] https://github.com/Motiejus/SoundPatty/
[3] http://marc.info/?l=git&m=130081966214059&w=4
[4] http://libgit2.github.com/api.html
[5] http://m.jakstys.lt/
[6] https://github.com/Motiejus/ :-)

Regards,
Motiejus Jakštys

             reply	other threads:[~2011-03-24  2:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-24  2:02 Motiejus Jakštys [this message]
2011-03-25 13:00 ` git2 cli (GSOC) Vicent Marti

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=20110324020232.GA10441@jakstys.lt \
    --to=desired.mta@gmail.com \
    --cc=git@vger.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.
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).