Thanks for the response! > Although there are few callers calling `have_git_dir`, I don't think > it's a good idea to remove the `have_git_dir`. This is because we need > to reomove the dependency on `startup_info`. It's not an easy thing. Oh, I will try to study more about it. > I somehow understand what you mean here. But "shift" may be not > accurate. When user sets the "core.*" in the command line or config > file, we will parse the setting and sets the _global_ state defined in > "environment.[ch]". We don't want to use these global variables, but > want to put these states into repo settings. > > So, we do not shift core.* into repo settings, but shift the global > variables which are related to the "core.*" or other settings to repo > settings. Right right, I went through it after your response, and understood what you are saying. > I think you could work on this but I don't think this would be a small > patch. You need some efforts to figure out the solution. You are on the > right direction. > > However, it's hard to suggest which files you need to read. This is > because that for each global state, there are many files which may use > this global state. So, you'd better follow the call stack to know which > functions you need to change. > > In conclusion, I somehow think that you could first think which states > you want to change. Try to figure out the most simplest global states. > Classify them by the complexity or difficulty thus you could write a > good proposal. Oh okay! I was thinking of creating a poc patch to get a better understanding of how to approach this during the timeline. > > Also are these patches ([1] and [2]) an example of how the project > > should be carried throughout the GSOC timeline? > > > > Exactly. > Thank you so much! (Sorry for the delayed reply, I have my university exams going on this week :') ) Regards, Ayush
