Re: [PATCH RFC v3 2/2] Move libgit.a sources into separate "lib/" directory

Junio C Hamano <[email protected]>
Newsgroups org.kernel.vger.git
Message-ID <[email protected]>
Johannes Schindelin <[email protected]> writes:

> Of course, it would be even nicer if `lib/` was split up further, but
> then:
>
> 1) You've got to start _somewhere_. As we saw with so many things on this
>    list, they never materialized because reviewers asked for too much and
>    weren't happy to get incremental improvements first.

That is why moving everything to 'lib/' and thinking about the rest
later will not work.  Instead, moving a specific component to a
specific subdirectory (not 'lib/') would be a reasonably
self-contained first step.  Consider 'builtin/' as an example:  it
is focused, and anyone can easily tell what the criterion is.  If
it is the top-level cmd_foo() implementation, it goes there;
otherwise, it does not.  Then, you can proceed to the second step,
and then the third.  Iterate enough times, and the top level will
become thin enough that you can either make your final step a
no-op and leave the remaining files there, or create one last
group to house the hodgepodge of leftover bits and move them there.

> 2) Naming is hard. As we saw with _many_ refactorings (I am thinking about
>    the low-level merge stuff as well as the ODB stuff, for example), it is
>    unlikely to get the origanization right the first time. So I'd think
>    that first moving the bulk of the library code to lib/ is a good start,
>    and worth merging, leaving later contributions to chop off further
>    parts into subdirectories of lib/.

Again, this is because you are trying to do everything at once.
Instead, come up with one clear concept, name it well, move the
related files there, and then iterate.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.