Re: git2 cli (GSOC)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>:
> 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@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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]