Junio C Hamano <gits...@pobox.com> writes:
> Ramkumar Ramachandra <artag...@gmail.com> writes:
>> Thiago Farina wrote:
>>> With some structure like:
>> 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
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.
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