{"thread":{"id":"36120","subject":"[GSOC] Git Configuration API improvements","startedAt":"2014-03-11T13:12:37Z","lastAt":"2014-03-15T16:30:29Z","messageCount":5,"participants":["karthik nayak","Matthieu Moy","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"236503","messageId":"CAOLa=ZSKDg9DKxTRMy4yWW7=ZHcudGmK4guYmaP2okxH8Q044Q@mail.gmail.com","threadId":"36120","inReplyTo":null,"subject":"[GSOC] Git Configuration API improvements","fromName":"karthik nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2014-03-11T13:12:37Z","receivedAt":"2014-03-11T13:12:37Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Hello to all,\n\nI'm Karthik Nayak, a Computer Science student from Bangalore India. I\nwill be applying for GSOC 2014. This is my first time applying for\nGSOC. I have been using Git for a long time now, so it would be an\nideal organisation for me to contribute to.\nAs suggested I completed the Micro Project under the guidance of Eric\nSunshine.[1]\n\nI went through the Idea's page[2] and the mails corresponding to the\ntopic[3]. Currently we have multiple invocation of git_config() in an\nindividual invocation of git() which is not efficient. Also, it is\nhard to implement new features, as mentioned -- such as allowing a\nconfiguration to be unset.\n\nThe basic idea is to use a data structure to store the config, the\nfirst time the git_config() is called. And refer to this each and\nevery time we invoke git_config() further. Jeff suggested [4] to use a\ntree or a mapping of keys to values which are stored in a string. I\nthink that the idea of storing using the config as a tree data\nstructure would be really advantageous.\n\nThis would allow us to easily implement modifications later, and can\nhelp to easily take care of duplicates being created on multiple usage\nof config set and unset. As, whenever a node's children have been\ndeleted the node can also be automatically deleted. The tree can be a\nstruct with values, header link and link to other configs. This way we\ncan also create functions to work on the tree easily.\n\nWould be great to hear your thoughts on this topic and also I plan to\nstart creating a proposal. Nice to have any suggestions or feedback of\nany kind.\n\nThank you,\nKarthik\n\n[1] : http://article.gmane.org/gmane.comp.version-control.git/243695/match=karthik+188+gmail+com\n[2] : http://git.github.io/SoC-2014-Ideas.html\n[3] : http://article.gmane.org/gmane.comp.version-control.git/243500/match=git+configuration+caching\n[4] : http://article.gmane.org/gmane.comp.version-control.git/243542\n"},{"id":"236506","messageId":"vpqsiqovleu.fsf@anie.imag.fr","threadId":"36120","inReplyTo":"CAOLa=ZSKDg9DKxTRMy4yWW7=ZHcudGmK4guYmaP2okxH8Q044Q@mail.gmail.com","subject":"Re: [GSOC] Git Configuration API improvements","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-03-11T14:51:05Z","receivedAt":"2014-03-11T14:51:05Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"karthik nayak writes:\n\n> Currently we have multiple invocation of git_config() in an\n> individual invocation of git() which is not efficient. Also, it is\n> hard to implement new features,\n\nI think efficiency is not a real concern here. Config files are small\nand easy to parse, so parsing them multiple times isn't really\nnoticeable from the performance point of view.\n\nOTOH, the extensibility is a real concern, and that should be the main\nmotivation for the project.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"236507","messageId":"CAOLa=ZQwrtvoBWEra-p9wwFmYBZqcz75a9R0qm7bv2g7UCJn4A@mail.gmail.com","threadId":"36120","inReplyTo":"vpqsiqovleu.fsf@anie.imag.fr","subject":"Re: [GSOC] Git Configuration API improvements","fromName":"karthik nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2014-03-11T16:19:33Z","receivedAt":"2014-03-11T16:19:33Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"On Tue, Mar 11, 2014 at 8:21 PM, Matthieu Moy\n wrote:\n> karthik nayak writes:\n>\n>> Currently we have multiple invocation of git_config() in an\n>> individual invocation of git() which is not efficient. Also, it is\n>> hard to implement new features,\n>\n> I think efficiency is not a real concern here. Config files are small\n> and easy to parse, so parsing them multiple times isn't really\n> noticeable from the performance point of view.\n>\n> OTOH, the extensibility is a real concern, and that should be the main\n> motivation for the project.\n>\n> --\n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n\nHello Matthieu,\n\nThanks. I understand what you mean. extensibility is the main motivation of the\nproject, i think that by implementing the cache system we can fix the\nsmall problems\n(reappearing of headers while setting and unsetting configs) and also\nimplement new features\nlike to unset a config easily.\n"},{"id":"236711","messageId":"20140314043141.GC31906@sigill.intra.peff.net","threadId":"36120","inReplyTo":"CAOLa=ZQwrtvoBWEra-p9wwFmYBZqcz75a9R0qm7bv2g7UCJn4A@mail.gmail.com","subject":"Re: [GSOC] Git Configuration API improvements","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-03-14T04:31:41Z","receivedAt":"2014-03-14T04:31:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 11, 2014 at 09:49:33PM +0530, karthik nayak wrote:\n\n> On Tue, Mar 11, 2014 at 8:21 PM, Matthieu Moy\n> wrote:\n> > karthik nayak writes:\n> >\n> >> Currently we have multiple invocation of git_config() in an\n> >> individual invocation of git() which is not efficient. Also, it is\n> >> hard to implement new features,\n> >\n> > I think efficiency is not a real concern here. Config files are small\n> > and easy to parse, so parsing them multiple times isn't really\n> > noticeable from the performance point of view.\n> >\n> > OTOH, the extensibility is a real concern, and that should be the main\n> > motivation for the project.\n>\n> Thanks. I understand what you mean. extensibility is the main motivation of the\n> project, i think that by implementing the cache system we can fix the\n> small problems\n> (reappearing of headers while setting and unsetting configs) and also\n> implement new features\n> like to unset a config easily.\n\nI think the most interesting part of the config idea is turning the\nfetching of config variables \"inside out\".\n\nThat is, right now we turn control over to the config code, which\ninvokes our callbacks. So we see all variables in sequence, and pick out\nthe ones that are interesting. We implement precedence with a \"last one\nwins\" technique where we keep overwriting a variable with subsequent\nconfig options.\n\nThis can lead to difficult ordering situations, such as when a config\noption _might_ be respected based on another factor (e.g., the presence\nof a command line option, as in the status.branch option).\n\nIt also means that it's impossible to tell after the fact whether a\nvalue was set explicitly on the command line, by config, or if we are\nusing a system default. Most of the time this doesn't matter, but there\nare a few cases where we care, and we end up having to manually manage\na separate flag in each case.\n\nBy the phrase \"inside out\" above, I mean that we could read all config,\nand then fetch individual values as we need them. We do need to care\nabout efficiency here, but only insofar as we don't cause any\nregressions (that is, the current system is fine speed-wise, we just\nneed to make sure that we do not create new problems by calling a slow\nlookup in a tight loop or anything like that).\n\n-Peff\n"},{"id":"236795","messageId":"CAOLa=ZTJOMSQnhT0RsdgGHcm61isYy==tbCGWz_PVZRBQj8wWw@mail.gmail.com","threadId":"36120","inReplyTo":"20140314043141.GC31906@sigill.intra.peff.net","subject":"Re: [GSOC] Git Configuration API improvements","fromName":"karthik nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2014-03-15T16:30:29Z","receivedAt":"2014-03-15T16:30:29Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"On Fri, Mar 14, 2014 at 10:01 AM, Jeff King wrote:\n> On Tue, Mar 11, 2014 at 09:49:33PM +0530, karthik nayak wrote:\n>\n>> On Tue, Mar 11, 2014 at 8:21 PM, Matthieu Moy\n>> wrote:\n>> > karthik nayak writes:\n>> >\n>> >> Currently we have multiple invocation of git_config() in an\n>> >> individual invocation of git() which is not efficient. Also, it is\n>> >> hard to implement new features,\n>> >\n>> > I think efficiency is not a real concern here. Config files are small\n>> > and easy to parse, so parsing them multiple times isn't really\n>> > noticeable from the performance point of view.\n>> >\n>> > OTOH, the extensibility is a real concern, and that should be the main\n>> > motivation for the project.\n>>\n>> Thanks. I understand what you mean. extensibility is the main motivation of the\n>> project, i think that by implementing the cache system we can fix the\n>> small problems\n>> (reappearing of headers while setting and unsetting configs) and also\n>> implement new features\n>> like to unset a config easily.\n>\n> I think the most interesting part of the config idea is turning the\n> fetching of config variables \"inside out\".\n>\n> That is, right now we turn control over to the config code, which\n> invokes our callbacks. So we see all variables in sequence, and pick out\n> the ones that are interesting. We implement precedence with a \"last one\n> wins\" technique where we keep overwriting a variable with subsequent\n> config options.\n>\n> This can lead to difficult ordering situations, such as when a config\n> option _might_ be respected based on another factor (e.g., the presence\n> of a command line option, as in the status.branch option).\n>\n> It also means that it's impossible to tell after the fact whether a\n> value was set explicitly on the command line, by config, or if we are\n> using a system default. Most of the time this doesn't matter, but there\n> are a few cases where we care, and we end up having to manually manage\n> a separate flag in each case.\n>\n> By the phrase \"inside out\" above, I mean that we could read all config,\n> and then fetch individual values as we need them. We do need to care\n> about efficiency here, but only insofar as we don't cause any\n> regressions (that is, the current system is fine speed-wise, we just\n> need to make sure that we do not create new problems by calling a slow\n> lookup in a tight loop or anything like that).\n>\n> -Peff\n\nHello Jeff,\nLike you said yes, this will be a complete \"inside out\" change. Thanks\nfor summing it up, really helpful.\nCurrently i am going through the code and understanding how it works currently.\nSimultaneously working on the proposal[1], would be great to have your\nfeedback on that.\nThanks,\nKarthik\n\n[1] https://gist.github.com/KarthikNayak/98569dd34326f7e6813a\n"}]}