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]> |
Patrick Steinhardt <[email protected]> writes: >> ... built-in commands in 'builtin', with subsystems like 'refs' and >> 'odb' in their own directories, and everything else at the root >> level, I would prefer to keep that organization until a substantial >> subsystem update wants to carve out a new location for itself, just >> as past updates to create 'builtin', 'refs', and 'odb' did. >> >> Compared to those past moves, the proposed change looks more like >> churn for the sake of moving things around, without achieving any >> real organizational improvement. >> >> I must say that I, too, remain skeptical. > > My main motivation isn't prettiness though, it's newcomers to the > project. Git is not an easy project to get started in, and the root > cause of that of course isn't our file layout but probably rather that > Git has been growing organically for 20 years. But the file layout > definitely doesn't help newcomers to find their way around in the > product. What I gave as good examples were not motivated by prettiness, either. Moving things around to lib/ as a whole ball of wax without further classification would mean readers, whether new or old, would not benefit from neatly classified set of files that gives readers a concise and easy to understand rules like "you can visit builtin to learn about individual command implementations". To achieve a layout that makes it easier to find our way around, you'd need to move things again after moving everything into lib/. Moving to lib/ by itself does not add much value, if any. It certainly does not add any discoverability.