Re: git2 cli (GSOC)
- From
Vicent Marti <vicent@github.com>
- Date
- Mar 25, 2011, 13:00 UTC
- Message-ID
- <AANLkTimHpRFSYTgiqiPonQGiEVZtkCeX_tJcVjjnNSaX@mail.gmail.com>
- In-Reply-To
- <20110324020232.GA10441@jakstys.lt>
Yo Motiejus,
sorry I missed this. That's quite the headstart you got going here (although maybe a little bit too ambitious). Of course there's people interested on mentoring this -- make sure you submit a proper application on Melange when the application period opens, and we'll look into it with more detail.
Cheers, Vicent Marti
2011/3/24 Motiejus Jakštys <desired.mta@gmail.com>:
Show 75 quoted lines
> 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 > -- > 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 >