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

From: Junio C Hamano <gitster@pobox.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Jeff King <peff@peff.net>, Vincent van Ravesteijn <vfr@lyx.org>,
	John Keeping <john@keeping.me.uk>,
	Ramkumar Ramachandra <artagnon@gmail.com>,
	git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
	Duy Nguyen <pclouds@gmail.com>
Subject: Re: [PATCH] build: get rid of the notion of a git library
Date: Tue, 11 Jun 2013 12:24:20 -0700	[thread overview]
Message-ID: <7vobbca1sr.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAMP44s3SL7qs-Pmfz=kV-4U5OnPedK2RDLZDOyU-eq8WebLt+Q@mail.gmail.com> (Felipe Contreras's message of "Tue, 11 Jun 2013 14:01:15 -0500")

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Tue, Jun 11, 2013 at 1:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> 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.
> ...
>> 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.