GSoC: Week 7
Week 7
Hello peeps!
So this week I sent the v6 of environment: remove sparse-checkout related global variables which I had prepared last week. I received comments from Junio saying that he did not mean to say that I should minimize the calls to prepare_repo_settings(), but what he meant was that we have calls to it all over the place, and we should try to centralize it. He asked me to explain why I decided to store these variables in the struct repo_settings and not the struct repository, to which Derrick replied saying that even he thinks that these variables should be a part of the struct repository because they are a core part of the repository. He also told me that the intention of the struct repo_settings was to store optional one-off feature flags, and if we’re trying to store core settings in it, then we should call prepare_repo_settings() when initializing the repository.
Here’s the message by Derrick:
I think that the core issue here (and probably causing the issues that were seen in the user-facing issues) is that the repo settings struct was intended as a place to fill config for some one-off “feature flags” and not to replace core functionality for a repo.
There are two ways to change the approach here to fix the problem of needing prepare_repo_settings() everywhere:
With the idea that these sparse-checkout variables are critical to the functionality of the repo, they should move into the repository struct itself and be initialized along with all other values there. This changes the patches (and my follow-up series) significantly, but mechanically.
If we are going to change the intention of the repo settings struct to move from “optional one-off feature flags” to “important information about the core behavior of a repo” then we should prepare_repo_settings() when initializing the repository struct.
My preference is (1). The only argument for (2) that I can think of is that it is sometimes helpful to share only the settings for a repo without sharing the whole repo. But that seems like a weak reason right now.
I also started working on a new topic which is to remove the global variable merge_log_config. So I tried creating a function in config.c which returns the value of the setting merge.log or merge.summary and using this function in builtin/fmt-merge-msg.c and merge.c replacing the use of the global variable.
My patch series: commit: improve behaviour of core.commentChar=auto for comments in commit messages, also got merged to master!
Thank you for reading my blog!
-Ayush:)