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

[Junio C Hamano <gitster@pobox.com>]

Michael Montalbo <mmontalbo@gmail.com> writes:

> Pointing forward, merging today's root .c files by that measure until
> cohesion drops below the carved band proposes these groups, with no
> hand-picked list [1]:
>
>   6.9  connect.c fetch-pack.c remote-curl.c send-pack.c transport.c
>        upload-pack.c
>   6.8  diff-lib.c entry.c read-cache.c unpack-trees.c
>   6.6  commit.c log-tree.c ref-filter.c revision.c sequencer.c
>   6.3  diff.c diffcore-rename.c merge-ort.c
>   6.0  delta-islands.c pack-bitmap-write.c pack-bitmap.c

We need to be careful about situations where a source file has to
include a header file only because a definition of one thing it uses
happens to be included in an otherwise out-of-place header file, and
moving such an out-of-place definition to a different header file
may affect mechanical groupings.  But with that caveat out of the
way, it is good when mechanical groupings match intuition.

And the earliest one in the list above actually does.  They form the
"transport" group.

The other groups in the list may not be so clear-cut, but this is an
interesting thought experiment that yielded a good, concrete result.
And as I said, we do not need to wait until we fully classify the
remainder.  When a conceptually clean group is identified, just as
when we created 'builtin/', 'refs/', or 'odb/', we can carve out a
new directory for it, and we will have moved one step closer to a
better place.

One tangential question is whether we can separate bisect and
revision machinery in such a way that bisect stands on its own,
without stronger ties to the revision machinery than other users,
such as 'rev-list' and 'log'.  "git rev-list --bisect" was a
historical accident that happened only because, back when "git
bisect" was a shell script, there was no good place to put the
logic, not because it was the best place for it.

Thanks.