Re: [PATCH] build: get rid of the notion of a git library

[Junio C Hamano <gitster@pobox.com>]

Felipe Contreras <felipe.contreras@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().