"Generic" repository layout #5296
Conversation
|
And, without further ado, here's my notes/questions about this undertaking :
The TL;DR is that, between the short-circuited codepaths of
I don't think "items" like Some others are less clear — I'm aware of "info/grafts" but it's along other files in "info", and the "*_MSG" ones are also kinda temporary ones… But there's still a transaction feel to them 🙄. Thus, I've chosen to add |
|
Annnnd I've de-drafted it 🤣. |
This introduces a string splitter to git_buf that works on static strings, and uses it as part of a strarray helper to assist in wrangling PATH_LIST-separated strings (a.k.a pathlists).
This changes the ceiling directories and ODB alternates lists, usually passed via the environment, to use strarrays instead of string manipulation.
As the number of places that expect a actual .git directory to exist increases, users of custom repository have started to encounter a varying amount of "brokenness", depending on how custom their repository are. As a first step to alleviate this, all used "names" are gathered in a new header, the `git_repository_layout` struct consolidates the "file-system resolution logic" already in place, and all users of direct file-system access are changed to go through that system.
Fish out the existing layout-related functions out of repository.c, and move them under a project-wide name.
Now that we have a generic layout object, convert the few members in `git_repository` to use a `git_repository_layout` instead, and require a layout object at initialization.
571e263 to
a09dd3d
Compare
This adds a low-level "layout" structure/subsystem, which inherits the current "filesystem resolution process" (a.k.a
git_repository_item_path()), and most of the "names"gituses. This allows the rest of the code to ask about "where do I find the data for $item", and be less knowledgable about any filesystem involvement (example). The longterm goal is clearly to deprecategit_repository_newand provide more easily-customizable options at a lower level, but that's out of scope for now — I just want the repository-opening step to be less confusing, and I want more control over what's considered valid and/or overridable 😉.This is actually a partial rebase of #4856, with a focus on refactoring/cleanups instead of feature-filling — mostly because IMHO there are low-level details that have completely conflicting semantics, and I can't manage to make sense of them when trying to preserve our own "rules" w.r.t to "opening from the environment". I don't know how much of it is in scope for #5291, hence I'm only drafting this 😉. Note that I don't intend to replace #4856 yet, since it's somehow closer to completion than this, but I'll either rebase later or polish up, fix and 🚢 if there's a need for it.