On Sat, Jun 8, 2013 at 9:23 PM, Jeff King <peff@xxxxxxxx> wrote: > 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. Perhaps one day we would end poverty and hunger, and perhaps one day we will live in peace, but I wouldn't hold on my breath. I fact, I'll do the opposite, I bet it won't happen anytime soon. >> 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? When you said in your opinion we should wait until libgit2 is ready, and not improve libgit.a. >> 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. Why is it closer? In what ways is it a better fit now than 2 years ago? What is missing before merging to be used in Git's core? > 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. And what are we waiting for then? Shouldn't we copy the whole libgit2 code and start migrating? >> > 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. It means this: http://article.gmane.org/gmane.comp.version-control.git/226752 I move code that doesn't belong in a libgit library out of libgit.a, and the change gets rejected. > 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), That is the second step. It doesn't make sense to make code re-entrant, if that code will only be used by builtin commands. First step is to move irrelevant code out of libgit.a. >> >> 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 did not. I made the assumption that there was a reason, if there's no reason to stay clear of libgit2, then let's merge it already. >> > 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 never said so. It is a dead end *if* we don't do an effort to have a proper libgit library, which is the path we are taking. > 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). You forgot the first step of 2.: move irrelevant code out of libgit.a. -- Felipe Contreras -- 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