{"thread":{"id":"6533","subject":"StGIT and repo-config","startedAt":"2007-01-25T22:55:12Z","lastAt":"2007-01-28T23:30:26Z","messageCount":8,"participants":["Yann Dirson","Catalin Marinas","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"32655","messageId":"20070125225512.GF4083@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6533","inReplyTo":null,"subject":"StGIT and repo-config","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-25T22:55:12Z","receivedAt":"2007-01-25T22:55:12Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"I'm trying to get StGIT to work with git's config information.\nCurrently, the stgit.config stuff uses a generic ConfigParser, which\nI'm not sure is adequate for the work:\n\n- it requires to forge section names like 'branch \"foo\"'\n- it is only a reader and I'm not sure it is easy to turn it to a\nwriter. It has a set() method, but it appears to only act on\nin-memory stuff.\n- since it parses the file at startup, it would not see any change\ndone from stgit by calling repo-config.\n- the canonical way to access the info is git-repo-config.\n\nI'd think this would be sufficient to rewrite stgit.config.\nNo objection ?\n\nBest regards,\n-- \nYann.\n"},{"id":"32663","messageId":"b0943d9e0701251545w1b34a0dcg545eeab08d767e38@mail.gmail.com","threadId":"6533","inReplyTo":"20070125225512.GF4083@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: StGIT and repo-config","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-01-25T23:45:45Z","receivedAt":"2007-01-25T23:45:45Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 25/01/07, Yann Dirson wrote:\n> I'm trying to get StGIT to work with git's config information.\n> Currently, the stgit.config stuff uses a generic ConfigParser, which\n> I'm not sure is adequate for the work:\n\nThere are some drawbacks indeed and it currently reads the configs and\ntransforms them slightly before passing them to ConfigParser. StGIT\ninitially had its own config files (git config came a bit later).\n\nIt would be good to have this re-written. It is even better to use\nsomething like config.get('user.name') rather than config.get('user',\n'name') as in ConfigParser.\n\nWhat I'd like it to have is a single initial call to git-repo-config\n--list (in config_setup) and all the options cached in a dictionary\n(so that .git/config options would override the global ~/.gitconfig\nones). The dictionary should also be pre-populated with the default\nvalues (only in memory, not going to the config file on disk).\n\nFor the options setting, it shouldn't probably need to use --global.\nAs above, these options should be cached in the dictionary as well.\n\n-- \nCatalin\n"},{"id":"32665","messageId":"Pine.LNX.4.63.0701260052590.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6533","inReplyTo":"b0943d9e0701251545w1b34a0dcg545eeab08d767e38@mail.gmail.com","subject":"Re: StGIT and repo-config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-25T23:58:38Z","receivedAt":"2007-01-25T23:58:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 Jan 2007, Catalin Marinas wrote:\n\n> What I'd like it to have is a single initial call to git-repo-config \n> --list (in config_setup) and all the options cached in a dictionary (so \n> that .git/config options would override the global ~/.gitconfig ones). \n> The dictionary should also be pre-populated with the default values \n> (only in memory, not going to the config file on disk).\n\nThere was another thread, a few days ago, where Jakub proposed an \nalternative config parser in Perl. Eric Wong even wrote a rather large \npatch to automatically generate _source_ code for Perl, Python and Ruby.\n\nI then proposed to have a simple --dump option to repo-config, which \noutputs NUL separated key/value pairs (substituting \"true\" for keys \nwithout -- not with empty! -- values). But somehow the discussion petered \nout before anything came out of it.\n\nThe most important point (to me) which came out of the discussion: It is \nnot at all easy, or straight-forward, to handle multi-vars, i.e. multiple \nvalues for the same key.\n\nCiao,\nDscho\n"},{"id":"32761","messageId":"20070126175302.GG4083@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6533","inReplyTo":"Pine.LNX.4.63.0701260052590.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: StGIT and repo-config","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-26T17:53:02Z","receivedAt":"2007-01-26T17:53:02Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, Jan 26, 2007 at 12:58:38AM +0100, Johannes Schindelin wrote:\n> On Thu, 25 Jan 2007, Catalin Marinas wrote:\n> > What I'd like it to have is a single initial call to git-repo-config \n> > --list (in config_setup) and all the options cached in a dictionary (so \n> > that .git/config options would override the global ~/.gitconfig ones). \n> > The dictionary should also be pre-populated with the default values \n> > (only in memory, not going to the config file on disk).\n\nPre-filling with default value has a drawback: it will create lots of\nuseless entries, especially for per-branch settings. I'd rather let\nthe accessors return the default value when needed. We can still\ngroup all defaults in a single dictionnary.\n\n\n> I then proposed to have a simple --dump option to repo-config, which \n> outputs NUL separated key/value pairs (substituting \"true\" for keys \n> without -- not with empty! -- values). But somehow the discussion petered \n> out before anything came out of it.\n\nEven if that was to be done in git, it would surely be post-1.5, so we\nneed another way to do things in the meantime.\n\n\n> The most important point (to me) which came out of the discussion: It is \n> not at all easy, or straight-forward, to handle multi-vars, i.e. multiple \n> values for the same key.\n\nRight, at least for filling a dictionnary. We would need to declare\nmulti-valued parameters as such, which basically means we must only\ntry to read those config items we know about, which has all sorts of\nconsequences for config.py :)\n\nIt would seem reasonable to start without a cache dictionnary, at\nleast for now. After all, there are not so many config items to know\nabout in a single stgit run, so IIMHO we're only going to notice a\ndifference for the time needed to run the testsuite.\n\nBest regards,\n-- \nYann.\n"},{"id":"32775","messageId":"b0943d9e0701261451y58062564yddad0a7471e0eff6@mail.gmail.com","threadId":"6533","inReplyTo":"20070126175302.GG4083@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: StGIT and repo-config","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-01-26T22:51:05Z","receivedAt":"2007-01-26T22:51:05Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 26/01/07, Yann Dirson wrote:\n> On Fri, Jan 26, 2007 at 12:58:38AM +0100, Johannes Schindelin wrote:\n> > On Thu, 25 Jan 2007, Catalin Marinas wrote:\n> > > The dictionary should also be pre-populated with the default values\n> > > (only in memory, not going to the config file on disk).\n>\n> Pre-filling with default value has a drawback: it will create lots of\n> useless entries, especially for per-branch settings. I'd rather let\n> the accessors return the default value when needed. We can still\n> group all defaults in a single dictionnary.\n\nWhat I meant is that it should pre-fill only with the default entries\nneeded by StGIT (probably around 10, see stgit.config.config_setup()).\nThe rest should be filled in when reading the config files.\n\n> > The most important point (to me) which came out of the discussion: It is\n> > not at all easy, or straight-forward, to handle multi-vars, i.e. multiple\n> > values for the same key.\n>\n> Right, at least for filling a dictionnary. We would need to declare\n> multi-valued parameters as such, which basically means we must only\n> try to read those config items we know about, which has all sorts of\n> consequences for config.py :)\n\nBut are multi-vars in the same file currently used? There is a clear\nsituation when a key is written in both the global and the\nper-repository config files. From the StGIT point of view, it should\nonly care about the most specific one, i.e. the one in the per-repo\nconfig and this would be the last one listed by git-repo-config (and\ntherefore overriding any preceding dictionary entry).\n\n> It would seem reasonable to start without a cache dictionnary, at\n> least for now. After all, there are not so many config items to know\n> about in a single stgit run, so IIMHO we're only going to notice a\n> difference for the time needed to run the testsuite.\n\nI'd like to avoid calling git-repo-config for every config option,\neven if this wouldn't be noticeable (initially, but the tool would\nevolve). If we don't care about multi-vars, as I said above, a\ndictionary cache would make sense.\n\n-- \nCatalin\n"},{"id":"32777","messageId":"Pine.LNX.4.63.0701270008410.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6533","inReplyTo":"20070126175302.GG4083@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: StGIT and repo-config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-26T23:12:36Z","receivedAt":"2007-01-26T23:12:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 26 Jan 2007, Yann Dirson wrote:\n\n> On Fri, Jan 26, 2007 at 12:58:38AM +0100, Johannes Schindelin wrote:\n>\n> > I then proposed to have a simple --dump option to repo-config, which \n> > outputs NUL separated key/value pairs (substituting \"true\" for keys \n> > without -- not with empty! -- values). But somehow the discussion petered \n> > out before anything came out of it.\n> \n> Even if that was to be done in git, it would surely be post-1.5, so we\n> need another way to do things in the meantime.\n\nI don't think it is too late. If it is simple enough, and stuck behind a \ncommand line option (not affecting the rest of repo-config), it is safe \nenough to include.\n\n> > The most important point (to me) which came out of the discussion: It is \n> > not at all easy, or straight-forward, to handle multi-vars, i.e. multiple \n> > values for the same key.\n> \n> Right, at least for filling a dictionnary. We would need to declare\n> multi-valued parameters as such, which basically means we must only\n> try to read those config items we know about, which has all sorts of\n> consequences for config.py :)\n\nWell, we have only two multi-valued keys at the moment (AFAIK): \nremote..fetch and remove..push.\n\nEven if there are more, they are hardly interesting to StGIT, right? So \nwhy not just pretend that they don't exist, by making a dictionary, \nputting each new key/value pair into it one by one? (Forgetting all but \nthe last value for multi-values...)\n\n> It would seem reasonable to start without a cache dictionnary, at least \n> for now. After all, there are not so many config items to know about in \n> a single stgit run, so IIMHO we're only going to notice a difference for \n> the time needed to run the testsuite.\n\nThe point is: it is very easy and short to just stash everything into a \ndictionary, and retrieve it from there.\n\nCiao,\nDscho\n"},{"id":"32820","messageId":"20070127103354.GE4036@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6533","inReplyTo":"Pine.LNX.4.63.0701270008410.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: StGIT and repo-config","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-27T10:33:54Z","receivedAt":"2007-01-27T10:33:54Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sat, Jan 27, 2007 at 12:12:36AM +0100, Johannes Schindelin wrote:\n> > Even if that was to be done in git, it would surely be post-1.5, so we\n> > need another way to do things in the meantime.\n> \n> I don't think it is too late. If it is simple enough, and stuck behind a \n> command line option (not affecting the rest of repo-config), it is safe \n> enough to include.\n\nThat would be great.\n\n> > > The most important point (to me) which came out of the discussion: It is \n> > > not at all easy, or straight-forward, to handle multi-vars, i.e. multiple \n> > > values for the same key.\n> > \n> > Right, at least for filling a dictionnary. We would need to declare\n> > multi-valued parameters as such, which basically means we must only\n> > try to read those config items we know about, which has all sorts of\n> > consequences for config.py :)\n> \n> Well, we have only two multi-valued keys at the moment (AFAIK): \n> remote..fetch and remove..push.\n> \n> Even if there are more, they are hardly interesting to StGIT, right?\n\nNot completely right. It is precisely remote..fetch I'm\nneeding, to be able to locate which remote a parent branch belongs to\nwhen creating a stack. It may be that the problem is git-remote being\ntoo limited, and if we implement the functionnality at that level,\nthen maybe we can ignore those config settings. But maybe not, since\nI'd like stack creation to record a remote..fetch entry.\n\n> So why not just pretend that they don't exist, by making a\n> dictionary, putting each new key/value pair into it one by one? \n> (Forgetting all but the last value for multi-values...)\n\nIMHO, that'd be the easiest way to shoot ourselves in the foot :)\n\n> > It would seem reasonable to start without a cache dictionnary, at least \n> > for now. After all, there are not so many config items to know about in \n> > a single stgit run, so IIMHO we're only going to notice a difference for \n> > the time needed to run the testsuite.\n> \n> The point is: it is very easy and short to just stash everything into a \n> dictionary, and retrieve it from there.\n\nOTOH, it is equally easy (if not easier) to call \"git repo-config\n--get\" or --get-all when needed :)\n\nBest regards,\n-- \nYann.\n"},{"id":"32936","messageId":"b0943d9e0701281530x791078ebk78070252251323a4@mail.gmail.com","threadId":"6533","inReplyTo":"20070127103354.GE4036@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: StGIT and repo-config","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-01-28T23:30:26Z","receivedAt":"2007-01-28T23:30:26Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 27/01/07, Yann Dirson wrote:\n> On Sat, Jan 27, 2007 at 12:12:36AM +0100, Johannes Schindelin wrote:\n> > Well, we have only two multi-valued keys at the moment (AFAIK):\n> > remote..fetch and remove..push.\n> >\n> > Even if there are more, they are hardly interesting to StGIT, right?\n>\n> Not completely right. It is precisely remote..fetch I'm\n> needing, to be able to locate which remote a parent branch belongs to\n> when creating a stack.\n\nYou could have a dictionary with list of values instead of just one\noverriding the former. The config object can have 2 methods -\nget_option(), returning config_dict[option][-1] (i.e. always the last,\nmost specific option) and get_moption() returning the whole list. The\ncode requiring the options should know which method to call for either\ngetting a single value or multiple values.\n\n> > The point is: it is very easy and short to just stash everything into a\n> > dictionary, and retrieve it from there.\n>\n> OTOH, it is equally easy (if not easier) to call \"git repo-config\n> --get\" or --get-all when needed :)\n\nIt is possible that we'll end up calling it too many times when\nworking on huge series (a very good benchmark is the -mm kernel\nseries, it really shows performance bottlenecks, mainly caused by GIT\noperations for writing the index).\n\nYou could also cache the values only when asked for an option the\nfirst time but given the relatively small size the config files, there\nisn't any performance impact in caching all the options at once.\n\n-- \nCatalin\n"}]}