On Sat, Jun 08, 2013 at 12:40:19PM -0500, Felipe Contreras wrote:
> > These are problems that can be solved. But there is a lot of work
> > involved in finding these subtle bugs and coming up with fixes. I think
> > you would be better off working on an implementation of git that was
> > designed from scratch to work in-process, like libgit2.
> So you are in favor of never ever having an official Git library. Got it.
No, I didn't say that at all.
I do think that it would be more work to try to slowly massage the git
code into a library-ready form than it would be to simply start with
more library-friendly code and pull in bits of git.git as appropriate.
That is what the libgit2 project is doing. Perhaps one day that project
will reach a point where we start building git.git commands off of it or
sometihng like it (for that matter, there is no reason you could not
build external commands off of libgit2 right now). Would it be the
"official" Git library then? I don't know. It is not clear to me what
that even means.
In the meantime, I think it cannot be a bad thing for libgit2 to proceed
along its path, and I don't see a good reason for people not to use it.
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.
> 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?
> As history indicates, the Git project will never have any pressure to
> fix it's re-entrancy and re-run issues, so these issues will remain
> there forever.
> Only if you allow code that exposes those issues will there ever be
> any pressure to fix them.
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html