Re: libgit2 status

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 19, 2012, 22:43 UTC
Message-ID: <7v4nlqhymd.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vvce6i5j2.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 18 quoted lines

> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Thiago Farina wrote:
>>> [...]
>>> With some structure like:
>>>
>>> include/git.h
>>> src/git.c
>>>
>>> ...
>>>
>>> whatever.
>>> [...]
>>
>> Junio- is it reasonable to expect the directory-restructuring by 2.0?
>
> I actually hate "include/git.h vs src/git.c"; you have distinction
> between .c and .h already.

Having said that, I do not mind moving codeblocks around to make some files purely library-ish while others purely commands.

Ideally, if you run

    $ nm --defined-only -g builtin/frotz.o

you should see nothing but "T cmd_frotz" (there are exceptions, most notably, what the commands in the "log" family do are so close with each other that builtin/log.o can define cmd_* for all of them).

    $ nm --defined-only -og builtin/*.o  | grep -v 'T cmd_'

a handful of offenders. If these functions with external linkage are truly useful across subcommands, we should move them to a more library-ish location.

It may require splitting the bits that are too closely tied to the external interface they are implementing from these functions, generalizing only the core-ish logic from them, and moving them to a more library-ish file as a preparatory step. Such a library-ish file may be created inside lib/ subdirectory from the get-go.

Until that kind of code restructure happens, I do not see much sense in just moving files, e.g. renaming revision.c to src/revision.c or lib/revision.c or somesuch.