-
Notifications
You must be signed in to change notification settings - Fork 809
Feature: user config attrs #23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8000
There are no files selected for viewing
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why we use ScopedStrings, instead of just load the config using the priority? Global, User, Project?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The primary reason is that we need to remember the scope for when / if we write the config back out to the underlying files. We need to know where each value came from (even if someone changed it).
I think we're either going to have to overhaul the Config stuff to not allow editing scoped values in the high-level structs or keep track of this scope information somewhere else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see but I rather not exposing this complex API. If we need to write back the config, we should request a clean copy of the Repository one (without any merge), and save this. It will be very complex and error-prone, allow persist a config from a different context.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The API on the scoped attrs is
.Value()
and.Set()
, which doesn't seem so complex. Would it help if this were consistent across all top-level config attrs? That would be a breaking change but if we made them private struct members we could then expose their names as getter methods (andSet[Attr]
for setters) so the migration would be fairly simple for users (i.e. just adding()
after the attr names everywhere).Currently there's nothing preventing writing configs because it's all based around public struct members. With un-scoped attrs, you set arbitrary struct members and then call
SetConfig
and suddenly your local.git/config
file contains the merged result of your system, global, and local configs. I think we would need some kind of breaking change to prevent that or this library is going to mess up peoples' configs in a way that will be a ticking time bomb for them (i.e. everything will seem normal until their repo hangs onto some global or system config param they change and assume applies everywhere).So it sounds like you're proposing some kind of new top-level, merged, read-only config. And if you want to be able to make change 10000 s to it, you have to request a specific scope's config which will be written back to that scope's corresponding file. This will be a breaking change, is that OK? Am I understanding your proposal correctly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is some things that are important:
Repository.Config
MUST return the repository config. Since it's a method from the repository and the goal is to operate with it.Storer.SetConfig
MUST not writeconfig.Config
structs with merged information.About how to identify the config, ideally is have a
MergedConfig
or something but since we can't change theConfig
to an interface, it should be done forv6
. So meanwhile we can addconfig.Config.Context
for example.Regarding reading the merged context, we can add
config.ReadConfig(context) config.Config
, as a helper for the people that wants access to this configuration. We must remember that the config merge is a very porcelain feature, so it's good to have it optional and explicit.Internally
Repository.Commit
my use the newconfig.ReadConfig
to read the config if a new flag called something likeCommitOpts.UseGlobalConfig
istrue
(by defaultfalse
)In this way, we have something that doesn't break the API or introduce unexpected behaviors. And we introduce an important feature requested by many users.
Thanks for your efforts and sorry for not being clear, but this library is a big codebase, and is hard to have it on top of the mind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cap10morgan are you planning to work on this soon? if not, I will take the task, I want to release a new version and I want to include this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I probably won't get to it soon. I'm no longer working on the project that needed this, so harder to prioritize spending work hours on it. Let me know if I can help with the effort in any other ways, though.