On Tue, Jun 11, 2013 at 2:24 PM, Junio C Hamano <gits...@pobox.com> wrote: > 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.
The first argument of init_copy_notes_for_rewrite() is the name of the builtin command. There hardly could be any more justification. >> 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. So? It's still hypothetical, which is what I said. What are you complaining about? About the fact that I made a correct assessment? > 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. Yeah, I already ran that argument, and you conveniently chose to escape the next logical conclusion that I already put forward: --- a/Makefile +++ b/Makefile @@ -990,6 +990,8 @@ BUILTIN_OBJS += builtin/verify-pack.o BUILTIN_OBJS += builtin/verify-tag.o BUILTIN_OBJS += builtin/write-tree.o +LIB_OBJS += $(BUILTIN_OBJS) + GITLIBS = $(LIB_FILE) $(XDIFF_LIB) EXTLIBS = I don't think that's the right direction. > 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. That's your opinion, and it's not shared by others (outside of the Git project). If you were right and Git was moving in the right direction, there would be no need for libgit2. -- Felipe Contreras -- 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
