{"thread":{"id":"36244","subject":"[GSOC 2014]idea:Git Configuration API Improvement","startedAt":"2014-03-20T07:23:40Z","lastAt":"2014-03-21T13:42:42Z","messageCount":7,"participants":["Yao Zhao","Michael Haggerty","Matthieu Moy","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"237146","messageId":"1395300220-7540-1-git-send-email-zhaox383@umn.edu","threadId":"36244","inReplyTo":null,"subject":"[GSOC 2014]idea:Git Configuration API Improvement","fromName":"Yao Zhao","fromEmail":"zhaox383@umn.edu","sentAt":"2014-03-20T07:23:40Z","receivedAt":"2014-03-20T07:23:40Z","isPatch":false,"sender":{"key":"zhaox383@umn.edu","avatar":null},"body":"Hello, Michael, Matthieu and peff,\n\nMy name is Yao and I am interested in Git Configuration API Improvements listed in idea page in Git. I came up some ideas and really want to discuss them with you.\n\nFirst is about when to start reading configuration file to cache. My idea is the time user starts call command that need configuration information (need to read configuration file).\n\nSecond is about data structure. I read Peff's email listed on idea page. He indicated two methods and I prefer syntax tree. I think there should be three or more syntax tree in the cache. One for system, one for global and one for local. If user indicate a file to be configuration file, add one more tree. Or maybe we can build one tree and tag every node to indicate where it belongs to.\n\nThird one is about when to write back to file, I am really confused about it. I think one way could be when user leave git repository using \"cd\" to go back. But I am not sure if git could detect user calls \"cd\" to leave repository.\n\nThank you,\n\nYao\n"},{"id":"237149","messageId":"532AAB39.3010507@alum.mit.edu","threadId":"36244","inReplyTo":"1395300220-7540-1-git-send-email-zhaox383@umn.edu","subject":"Re: [GSOC 2014]idea:Git Configuration API Improvement","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-03-20T08:47:53Z","receivedAt":"2014-03-20T08:47:53Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/20/2014 08:23 AM, Yao Zhao wrote:\n> Third one is about when to write back to file, I am really confused\n> about it. I think one way could be when user leave git repository\n> using \"cd\" to go back. But I am not sure if git could detect user\n> calls \"cd\" to leave repository.\n\nI don't understand. The cache would be in memory, and would only live\nas long as a single \"git\" process. Within that process, if somebody\nwants to change the config, they might (for example) call one function\nto lock the config file, a second function to change the value(s) in\nmemory, and then a third function to flush the new config out to disk\nand unlock the config file again. The cache would usually only live for\nmilliseconds, not minutes/hours, so I don't think your question really\nmakes sense.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"237150","messageId":"vpqd2hh5j7k.fsf@anie.imag.fr","threadId":"36244","inReplyTo":"1395300220-7540-1-git-send-email-zhaox383@umn.edu","subject":"Re: [GSOC 2014]idea:Git Configuration API Improvement","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-03-20T09:10:23Z","receivedAt":"2014-03-20T09:10:23Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Hi,\n\nYao Zhao writes:\n\n> First is about when to start reading configuration file to cache. My\n> idea is the time user starts call command that need configuration\n> information (need to read configuration file).\n\nI'd actually load the configuration lazily, when Git first requires a\nconfiguration variable's value. Something like\n\nint config_has_been_loaded = 0;\n\ngit_config() {\n\tif (!config_has_been_loaded) {\n\t\tload_config();\n\t\tconfig_has_been_loaded = 1;\n\t} else if (cache_is_outdated()) {\n\t\tload_config();\n\t} else { /* Nothing to do, we're good */ }\n\tdo_something_with_loaded_config();\n}\n\n> Second is about data structure. I read Peff's email listed on idea\n> page. He indicated two methods and I prefer syntax tree.\n\nWhy?\n\n(In general, explaining why you chose something is more important than\nexplaining what you chose)\n\n> I think there should be three or more syntax tree in the cache. One\n> for system, one for global and one for local. If user indicate a file\n> to be configuration file, add one more tree. Or maybe we can build one\n> tree and tag every node to indicate where it belongs to.\n\nA tree (AST, Abstract syntax tree) can be interesting if you have some\nsource-to-source transformations to do on the configuration files (i.e.\nedit the config files themselves).\n\nFor read-only accesses, I would find it more natural to have a\ndata-structure that reflects the configuration variables themselves, not\nthe way they appear in the config file. For example, a map (hashtable)\nassociating to each config variable the corresponding value (which may\nbe a scalar value or a list, depending on the variable).\n\nBut the really important part here is the API exposed to the user, not\nthe internal data-structure. A map would be \"more efficient\" (O(1) or\nO(log(n)) access), but traversing the AST for each config request would\nnot really harm: this is currently what we're doing, except that we\ncurrently re-parse the file each time. OTOH, the API should hide the AST\nfor most uses. If the user wants the value of configuration variable\n\"foo\", the code to do that should not be much more complex than\nget_value_for_config_variable(\"foo\"). (well, I did oversimplify a bit\nhere).\n\n> Third one is about when to write back to file, I am really confused\n> about it. I think one way could be when user leave git repository\n> using \"cd\" to go back. But I am not sure if git could detect user\n> calls \"cd\" to leave repository.\n\nThere semes to be a misunderstanding here. The point of the project is\nto have a per-process cache, but Git does not normally store a state in\nmemory between two calls. IOW, when you run\n\n git status\n cd ../\n git log\n\nThe call to \"git status\" creates a process, but the process dies before\nyou run \"cd\". The call to \"git log\" is a different process. It can\nre-use things that \"git status\" left on disk, but not in-memory data\nstructures.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"237186","messageId":"xmqqbnx0zsa3.fsf@gitster.dls.corp.google.com","threadId":"36244","inReplyTo":"vpqd2hh5j7k.fsf@anie.imag.fr","subject":"Re: [GSOC 2014]idea:Git Configuration API Improvement","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-20T17:36:20Z","receivedAt":"2014-03-20T17:36:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Why?\n>\n> (In general, explaining why you chose something is more important than\n> explaining what you chose)\n\nGood educational comment. Thanks.\n\n> A tree (AST, Abstract syntax tree) can be interesting if you have some\n> source-to-source transformations to do on the configuration files (i.e.\n> edit the config files themselves).\n>\n> For read-only accesses, I would find it more natural to have a\n> data-structure that reflects the configuration variables themselves, not\n> the way they appear in the config file.\n\n... and one important thing that was left unsaid is that the\nread-only accesses happen far more often than updates, so the data\nstructure must be optimized for the read-only look-up case.\n"},{"id":"237208","messageId":"1395350103-4899-1-git-send-email-zhaox383@umn.edu","threadId":"36244","inReplyTo":"vpqd2hh5j7k.fsf@anie.imag.fr","subject":"Re: Re: [GSOC 2014]idea:Git Configuration API Improvement","fromName":"Yao Zhao","fromEmail":"zhaox383@umn.edu","sentAt":"2014-03-20T21:15:03Z","receivedAt":"2014-03-20T21:15:03Z","isPatch":false,"sender":{"key":"zhaox383@umn.edu","avatar":null},"body":"I think I misunderstand the project as Moy said. I thought the purpose of project is to store configuration into memory between multiple git calls. Sorry.\n\nMoy, thanks for explaining. You said API should be hided. Is that means I should indicate an arbitary feature in old version or new feature we added should be linked to a manipulation of inner structure? And I need to find the connection to make this abstraction?\n\nBesides maybe I should focus on code part more in my proposal, like which part should be changed for this project?\n"},{"id":"237304","messageId":"vpqob10dko5.fsf@anie.imag.fr","threadId":"36244","inReplyTo":"1395350103-4899-1-git-send-email-zhaox383@umn.edu","subject":"Re: [GSOC 2014]idea:Git Configuration API Improvement","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-03-21T08:23:54Z","receivedAt":"2014-03-21T08:23:54Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Yao Zhao writes:\n\n> Moy, thanks for explaining. You said API should be hided. Is that\n> means I should indicate an arbitary feature in old version or new\n> feature we added should be linked to a manipulation of inner\n> structure? And I need to find the connection to make this abstraction?\n\nSorry, I do not understand what you mean.\n\nThe new code should be backward compatible with the old one, that is:\nexisting code using git_config() should continue working. There are a\nlot of git_config() calls in the codebase, and a GSoC won't have time to\nchange them all into something new.\n\nThis does not mean we can't add new features, both on the file parsing\nside (add the ability to unset a key) and on the user API side (allow\ngetting the value of a key more easily).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"237311","messageId":"vpqfvmb3bxp.fsf@anie.imag.fr","threadId":"36244","inReplyTo":"CAP4BmmHAuWYgeMvk11ywJ5eXQunCWPepGEE3UTKfiVn60RQVrw@mail.gmail.com","subject":"Re: [GSOC 2014]idea:Git Configuration API Improvement","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-03-21T13:42:42Z","receivedAt":"2014-03-21T13:42:42Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Mustafa Orkun Acar writes:\n\n> Hi, \n> I have completed my proposal about this project. But in one of the previous emails; it says that the aim of the project is not storing configuration data in the memory instead of making multiple git_config() calls. I\n> also understand the project in this way. I need a clarification about it. Thanks.\n\nSee my explanations at the bottom of\n\nhttp://article.gmane.org/gmane.comp.version-control.git/244522\n\nThe goal _is_ to keep the configuration in memory, inside a single git\nprocess. Not to maintain it in memory when the process dies (this would\nrequire an additional daemon, which would be really overkill in our\ncase).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"}]}