<dag@xxxxxxxx> writes:
> Nicolas Sebrecht <nicolas.s.dev@xxxxxx> 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 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.
>
> This makes a lot of sense to me.
As I already said in my earlier message in $gmane/204305, I wouldn't
be surprised if some "core stuff" gets reimplemented on top of
libgit2 and distributed as part of the git-core. But at this
moment, I see that just as a blip of possibility far in the future.
It would most likely start slowly, by adding lg-client/cat-file.c
that is linked with libgit2 when "make USE_LIBGIT2=YesPlease" was
asked for, and we compile the tried-and-true builtin/cat-file.c
otherwise ("cat-file" may actually not the most trivial first step,
though, but I think readers get the idea).
Even after most if not all commands have counterparts reimplemented
on libgit2, I do not think we can afford to drop any of the original
for a long time. For that to happen, at the very least:
- libgit2 must be available in major distros so that people can say
"[yum|apt-get] install libgit2-dev"; and
- the version of it packaged for major distros are recent and
stable enough, so that we never have to say "distro X ships with
libgit2 that is too old, so people on that distro have to compile
it from the source."
which is the quality we expect from libraries we would depend on,
like -lz, -lcurl, etc.
It is OK if we have to conditionally compile out some of our code in
the periphery when libgit2 that is available on the platform is too
old (we allow it for -lcurl already).
But all of the above assumes one thing: the reimplementated result
does not suck ;-) which is a large unknown.
--
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