What is the status of libgit2 WRT the overall git project? I recall
that there was some discussion of basing bits of git on libgit2 once it
matures.
I ask because I'm starting a project to improve the abysmal speed of
git-subtree split. It's unbearably slow at the moment and as far as I
can puzz
On 08/24/2012 04:02 PM, gree...@obbligato.org wrote:
> What is the status of libgit2 WRT the overall git project? I recall
> that there was some discussion of basing bits of git on libgit2 once it
> matures.
>
> I ask because I'm starting a project to improve the abysmal speed of
> git-subtree sp
On Sat, Aug 25, 2012 at 2:56 AM, Andreas Ericsson wrote:
> Politically, I'm not sure how keen the git community is on handing
> over control to the core stuff of git to a commercial entity,
The development of libgit2 happens 100% in the open. I don't know what
"commercial entity" are you talking
The 25/08/12, Vicent Marti wrote:
> The development of libgit2 happens 100% in the open. I don't know what
> "commercial entity" are you talking about, but there are several
> companies and independent contributors working on the Library at the
> moment.
Right but as far as I'm aware of Junio had
Nicolas Sebrecht writes:
> The 25/08/12, Vicent Marti wrote:
>
>> The development of libgit2 happens 100% in the open. I don't know what
>> "commercial entity" are you talking about, but there are several
>> companies and independent contributors working on the Library at the
>> moment.
>
> Right
I know julio notes about libgit2. Anyway the rpm5 mantainer had
decided to integrate libgit2 recently. Jfi.
Regards
2012/8/25, Nicolas Sebrecht :
> The 25/08/12, Vicent Marti wrote:
>
>> The development of libgit2 happens 100% in the open. I don't know what
>> "commercial entity" are you talking
Andreas Ericsson writes:
> Politically, I'm not sure how keen the git community is on handing
> over control to the core stuff of git to a commercial entity, but it
> doesn't seem to be a dying project, so I'd say go ahead and do it.
I do not think commercial-ness of any entity comes into the pi
Junio C Hamano writes:
> Looking at the build dependency of libgit2 itself, I do not think
> tighter integration of the libgit2 itself into the git-core is not
> likely to happen very soon, and also is not necessarily a good thing
> to do.
Obviously I meant "I think it is not likely to happen an
Junio C Hamano writes:
> And the last one should really be a "longer term" item. It is more
> important for its codebase to get mature and robust, and that can
> only happen by various projects and products (e.g. GitHub for Mac)
> using it to improve it. I do not think "subtree" (or anything in
writes:
> I am hoping to move git-subtree into core once it performs a little
> better and I've fixed a couple of bugs. Will basing it on libgit2 delay
> that process significantly? Six months delay is no problem. 2 years
> would be problematic.
>
> I would be happy to be a guinea pig for libg
Junio C Hamano writes:
>> I would be happy to be a guinea pig for libgit2 in order to improve it,
>> but I don't want to significantly impact git-subtree's move to core.
>> I'll have to figure out the right balance there given feedback.
>
> I expect it will take some time for libgit2 to allow our
writes:
> Junio C Hamano writes:
>
>>> I would be happy to be a guinea pig for libgit2 in order to improve it,
>>> but I don't want to significantly impact git-subtree's move to core.
>>> I'll have to figure out the right balance there given feedback.
>>
>> I expect it will take some time for li
Junio C Hamano writes:
>> Well that's a chicken-and-egg problem, isn't it. How will a library
>> become widespread unless something uses it?
>
> That something will not be the git core itself. Otherwise we will
> lose a stable reference implementation to catch its bugs.
Well, the whole questio
The 27/08/12, Junio C Hamano wrote:
> writes:
>
> > Junio C Hamano writes:
> >
> >>> I would be happy to be a guinea pig for libgit2 in order to improve it,
> >>> but I don't want to significantly impact git-subtree's move to core.
> >>> I'll have to figure out the right balance there given feed
Nicolas Sebrecht writes:
> Do you expect one big merge of a very stable libgit2 at some point?
I don't think there's any need to merge libgit2 into the git project
source. As a library, it should be perfectly usable as a project of its
own, just like libcurl and libz.
> Otherwise, what about g
writes:
> Nicolas Sebrecht writes:
>
>> Do you expect one big merge of a very stable libgit2 at some point?
>
> I don't think there's any need to merge libgit2 into the git project
> source. As a library, it should be perfectly usable as a project of its
> own, just like libcurl and libz.
>
>>
Ramkumar Ramachandra writes:
> Thiago Farina wrote:
>> [...]
>> With some structure like:
>>
>> include/git.h
>> src/git.c
>>
>> ...
>>
>> whatever.
>> [...]
>
> Junio- is it reasonable to expect the directory-restructuring by 2.0?
I actually hate "include/git.h vs src/git.c"; you have distincti
Junio C Hamano writes:
> I actually hate "include/git.h vs src/git.c"; you have distinction
> between .c and .h already.
+1
-David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
Junio C Hamano writes:
> Ramkumar Ramachandra writes:
>
>> Thiago Farina wrote:
>>> [...]
>>> With some structure like:
>>>
>>> include/git.h
>>> src/git.c
>>>
>>> ...
>>>
>>> whatever.
>>> [...]
>>
>> Junio- is it reasonable to expect the directory-restructuring by 2.0?
>
> I actually hate "inc
On 10/19/2012 10:13 PM, Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> Thiago Farina wrote:
>>> [...]
>>> With some structure like:
>>>
>>> include/git.h
>>> src/git.c
>>>
>>> ...
>>>
>>> whatever.
>>> [...]
>>
>> Junio- is it reasonable to expect the directory-restructuring by 2.0?
>
20 matches
Mail list logo
