From: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
To: Junio C Hamano <gitster@pobox.com>
Cc: dag@cray.com, Andreas Ericsson <ae@op5.se>,
greened@obbligato.org, git@vger.kernel.org,
Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
Subject: Re: libgit2 status
Date: Mon, 27 Aug 2012 23:40:27 +0200 [thread overview]
Message-ID: <20120827214027.GA511@vidovic> (raw)
In-Reply-To: <7v6284qfw8.fsf@alter.siamese.dyndns.org>
The 27/08/12, Junio C Hamano wrote:
> <dag@cray.com> writes:
>
> > Junio C Hamano <gitster@pobox.com> 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 Makefile to
> >> start saying "LDFLAGS += -libgit2"; it will need to become as stable
> >> and widespread as other libraries we depend on, e.g. -lz and -lcurl.
> >
> > 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.
This is exactly what I'm most afraid about. I tend to think it's a
chicken-and-egg problem, too.
Do you expect one big merge of a very stable libgit2 at some point?
Because, asking others to implement widely used tools on top of libgit2
in order to have it as stable/tested as curl is not going to happen, IMHO.
Otherwise, what about going with this optionnal "LDFLAGS += -libgit2"
ASAP with good disclaimer that it's only intended for development and
testing purpose? Then, git-core could slowly rely on functions of
libgit2, one after the other.
--
Nicolas Sebrecht
next prev parent reply other threads:[~2012-08-27 21:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-24 14:02 libgit2 status greened
2012-08-25 9:56 ` Andreas Ericsson
2012-08-25 20:46 ` Vicent Marti
2012-08-25 21:46 ` Nicolas Sebrecht
2012-08-25 22:32 ` Carlos Martín Nieto
2012-08-26 7:26 ` Elia Pinto
2012-08-26 18:28 ` Junio C Hamano
2012-08-26 18:56 ` Junio C Hamano
2012-08-27 16:13 ` dag
2012-08-27 17:10 ` Junio C Hamano
2012-08-27 18:49 ` dag
2012-08-27 19:44 ` Junio C Hamano
2012-08-27 21:21 ` dag
2012-08-27 21:40 ` Nicolas Sebrecht [this message]
2012-08-28 17:59 ` dag
2012-08-28 18:36 ` Junio C Hamano
2012-10-19 0:42 ` Thiago Farina
2012-10-19 3:54 ` Ramkumar Ramachandra
2012-10-19 20:13 ` Junio C Hamano
2012-10-19 22:11 ` dag
2012-10-19 22:43 ` Junio C Hamano
2012-10-20 1:21 ` Thiago Farina
2012-10-20 7:58 ` Andreas Ericsson
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=20120827214027.GA511@vidovic \
--to=nicolas.s.dev@gmx.fr \
--cc=ae@op5.se \
--cc=dag@cray.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=greened@obbligato.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.