On Sat, Jun 08, 2013 at 08:17:08PM -0500, Felipe Contreras wrote:
> > No, I didn't say that at all.
>
> Then you truly think libgit2 will ever reach the point where it can
> replace libgit.a?
I don't know. It may. Or something like it may. It is certainly not
ready to do so yet, but perhaps one day it will be.
> It won't.
Oh, I see, you were not actually interested in my answer and were just
being rhetorical.
> But decreeing that both projects should remain isolated, and
> that libgit.a should never be a library, you are effectively
> condemning the effort to fail, knowingly or not.
Huh? When did I decree anything? You asked Duy what kinds of problems
you would run into with running multiple git commands in the same
process space. I answered with concrete examples, and gave my opinions
on what the path of least work would be to reach a re-entrant library.
You don't have to agree (didn't I even say "you don't have to listen to
me" in the last email?).
> How many years has libgit2 been brewing? Do you think it's closer for
> merging so it can be used by Git's core? No, it doesn't, and it will
> not in the future, because it was never meant for that.
There has been about 2 years of active development, and there's been
quite a lot of improvement in that time. Closer than what? Than it was 2
years ago? Yes, I think it is. But it still has a ways to go.
I do not think there will be a flag day where we throw away git.git's
code and start using libgit2. But we could slowly start replacing
underlying bits with libgit2 bits, if that implementation proves to be
robust and clean enough to do so.
> > But hey, you don't need to listen to me. If you think it would be easier
> > to make the git.git code into a library, go ahead and work on it. But I
> > think you will find that there are a large number of hard-to-find bugs
> > caused by implicit assumptions about global state, how file descriptors
> > are used, and so forth.
>
> That's impossible. Specially since moving irrelevant code out of
> libgit.a is not permitted.
I'm not even sure what your second sentence means.
But it seems to me that the first step would be cleaning up the internal
code so that it is more friendly to library callers (both in interface
and in being re-entrant), with those first sets of callers being the
existing code in git.git. Such cleanups would be a good thing for the
modularity of the code, even without an intended library step.
And then you can start to pull out individual interfaces that are known
to be safe for library use, and think about making a coherent library
out of them.
And please don't tell me about "not permitted". You are free to fork and
work on this. But do not expect people who have already said "that does
not seem like a fruitful path to me" to jump into it with you. If you
think it is worth doing and that you can come up with initial results to
convince others, go for it.
> >> There's a reason why the Git project doesn't use libgit2, and for the
> >> same reason the official Ruby scripts should not use it.
> >
> > What reason is that?
>
> You tell me. Why isn't Git using libgit2?
Wait, you indicated you had such a reason in mind, but now you won't
tell me? Is it a secret?
> > I think it is a matter of critical mass. If you were to start linking
> > against libgit.a and 90% of it worked, you might have a reason to fix
> > the other 10%. But I suspect it is more the other way around.
>
> It doesn't matter if it's 90% or 10%, it's the only thing we have.
>
> Unless you are in favor of including libgit2 and start using it for
> Git's core *right now*, the only way forward is to improve libgit.a.
That seems like a false choice to me. You obviously feel that libgit2 is
some kind of dead end. I don't agree. Whatever.
I have very little interest in discussing this further with you, as it
is not leading in a productive direction. In my opinion, the productive
things to do would be one (or both) of:
1. Work on libgit2.
2. Clean up non-reentrant bits of git.git, hopefully making the code
more readable and more modular (and taking care not to make it
worse in other ways, like maintainability or performance).
-Peff
--
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