Felipe Contreras <felipe.contre...@gmail.com> writes: > Moreover, if you are going to argue that we shouldn't be closing the > door, then why not link ./builtin/*.o to libgit.a?
Huh? It does not make any sense. builtin/*.o files have cmd_foo() that are expected to be called from git.c::main(), but libgit.a files are linked with no constraints whose main() they are linking with. > If you are > seriously considering the highly unlikely hypothetical standalone > git-filter-branch scenario, you should consider the even more likely > scenario where somebody needs to access code from ./builtin/*.o; that > scenario is not even hypothetical, we know it's happened multiple > times, and we know it's going to happen again. That is exactly why I said that builtin/*.o should be refactored to pick "does not have to be in builtin" bits, which will result in a better division of labor. Reusable bits should live in the library, while a particular implementation of command remain in builtin/* that utilize the reusable bits. You still haven't justified why we have to _forbid_ any outside callers from calling copy_notes_for_rewrite(). -- 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
