On Sat, Jun 8, 2013 at 7:10 PM, Jeff King <peff@xxxxxxxx> wrote: > 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. Then you truly think libgit2 will ever reach the point where it can replace libgit.a? It won't. 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. 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. > 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. It might be more effort, but the results are guaranteed by our extensive testing infrastructure and huge user-base. Slowly but steadily we'll get there. Waiting for libgit2 to switch directions and reach some hypothetical point is waiting for hell to freeze. It won't happen. There's no incentive nor reason for it to happen. > 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. It means 'make install' installs a shared library with a clearly defined and stable API that other projects can depend on, and it can be used for all sort of purposes, including the git binary, and it's builtins. > 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. Its path will never end as an official Git library, not unless we do something. > 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. >> 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? >> 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. 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. -- 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