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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 11, 2013, 18:17 UTC
Message-ID: <7vd2rsbjgr.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAMP44s02KaMaMUz4618n5RqVqVSXzr_D9rPS1uesy2XEdqnq5A@mail.gmail.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.

Show 6 quoted lines

> 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().