Felipe Contreras <felipe.contre...@gmail.com> writes: > On Tue, Jun 11, 2013 at 1:17 PM, Junio C Hamano <gits...@pobox.com> wrote: >> 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. > ... >> 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(). > > Because only builtins _should_ use it.
And there is no justification behind that "_should_" claim; you are not making any technical argument to explain it. > I asked you for an example, and > you said a hypothetical standalone 'git-filter-branch' might use it, Of course it has to be hypothetical; I already said with the current code no standalone does use it---it is not arranged to be doable so there is no user. If you want to have examples of future possible callers, they have to be hypothetical---the future by definition hasn't happened. But that does not mean hypothetical is impractical nor useless. There are out-of-tree programs like cgit that will not be built-in but already link with libgit.a. Moving things that can be used by outside people out of builtin/*.o to libgit.a would allow uses that you and I cannot imagine offhand. I do not see a reason for us to forbid a filter-branch replacement out of tree as a standalone. I do not see a point in continuing to discuss this (or any design level issues) with you. You seem to go into a wrong direction to break the design of the overall system, not in a direction to improve anything. I do not know, and at this point I do not care, if you are doing so deliberately to sabotage Git. Just stop. -- 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
