New ConfigManager, Repo, and Worktree
#19
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #19 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 6 27 +21
Lines 72 882 +810
Branches 2 54 +52
==========================================
+ Hits 72 882 +810 ☔ View full report in Codecov by Sentry. |
mih
commented
Oct 2, 2024
mih
commented
Oct 2, 2024
mih
commented
Oct 2, 2024
mih
commented
Oct 2, 2024
mih
force-pushed
the
config
branch
6 times, most recently
from
a7f287d to
73f9aac
Compare
mih
force-pushed
the
config
branch
8 times, most recently
from
ac96ef0 to
3a897f9
Compare
mih
changed the title
ConfigManager, Repo, and Worktree
Clarity can benefit from having base classes with common implementation that we nevertheless do not expose directly in a (sub)package. This change ensures that appropriate documentation for class members inherited from such private classes is rendered.
The initial content is taken from legacy DataLad and is largely focused on the composition of a dataset.
5 tasks
This new implementation represents a substantial departure from the relatively thin wrapper around `git-config` that is used in legacy DataLad. It is based on the `Settings` class from `datasalad`, and extends it with additional features, for example a context manager to temporarily amend or override configuration items (see datalad/datalad#5155). Unlike legacy DataLad, no global config manager instance is created on import. Instead, a `get_manager()` function is provided that can be called by any code that requires access to a global manager instance. A number of additional implementations of setting sources are provided, most notably individual sources for all of Git's configuration scopes. This now also includes a `git-worktree` scope, not supported by legacy DataLad. All sources use a dedicated `ConfigItem` class for individual settings. At present, this is identical to a `datasalad` `Setting`. However, this item class will be extended to support UI-based query for configuration values in the future. This is not implemented yet. A dedicated `ImplementationDefaults` source (singleton) is included in any `ConfigManager` instance. It can be populated with application specific defaults (on import). This commit also introduced type-coercion for few standard Git configuration items using this feature.
mih
force-pushed
the
config
branch
3 times, most recently
from
411ebfd to
5290c72
Compare
There are no direct equivalents in legacy DataLad for the classes `Repo` and `Worktree`. The closest would be `GitRepo`, but this is a compound representation of a Git repository with an associated checkout. In comparison, `Repo` and `Worktree` is more focused, simpler models with leaner implementations. A `Repo` is a Git repository (location). It is conceptually identical to what is called GIT-DIR in the Git documentation. It refers to just the "bare" components of a repository, not to any potential checkout. A `Repo` features a dedicated `ConfigManager` that is derived from a global instances, sharing all common sources (actually using the exact same source instances). It adds a `git-local` and a `datalad-branch` configuration scope. The latter is added for semantic compatibility with legacy DataLad, which reads the committed configuration from the configured HEAD branch of a bare repo also. A `Worktree` is a primary checkout (of a non-bare) Git repository, or any (linked) additional Git worktree. A `Worktree` always has an associated `Repo`, accessible via its `.repo` property. With `extensions.worktreeConfig` enabled in Git, `Worktree` provides a tailored `ConfigManager` with an additional `git-worktree` scope. Otherwise is uses the manager of the underlying `Repo`. Both classes implement the "flyweight" pattern, like it is done in legacy DataLad. This means that, within the same process, creating instances of `Repo` and `Worktree` always yields the same instance for the same path location. This enables a straightforward implementation of cleanup routines, locking, but also sharing `ConfigManager` instances and their sources. In comparison to legacy DataLad, the flyweight pattern implementation is simplified. Only classes with a single `path` parameter are supported. Importantly, neither `Repo` nor `Worktree` class constructors support the actual creation of a repository or worktree "on disk".
Both `Repo` and `Worktree` have received `init_at()` class methods. The present implementation is focused on bare necessities: (re)initialization in an existing directory. The `Worktree.init_at()` implementation supports the git-init feature for repository relocation, and it takes care of suitable instance invalidation. This is a prelimary implementation. The criticial test will be whether `git-init` can relocate a repository with an annex. A corresponding tests needs to be added when an `init_annex()` method becomes available.
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.