On Sat, Jan 27, 2007 at 12:12:36AM +0100, Johannes Schindelin wrote: > > Even if that was to be done in git, it would surely be post-1.5, so we > > need another way to do things in the meantime. > > I don't think it is too late. If it is simple enough, and stuck behind a > command line option (not affecting the rest of repo-config), it is safe > enough to include. That would be great. > > > The most important point (to me) which came out of the discussion: It is > > > not at all easy, or straight-forward, to handle multi-vars, i.e. multiple > > > values for the same key. > > > > Right, at least for filling a dictionnary. We would need to declare > > multi-valued parameters as such, which basically means we must only > > try to read those config items we know about, which has all sorts of > > consequences for config.py :) > > Well, we have only two multi-valued keys at the moment (AFAIK): > remote.<branch>.fetch and remove.<branch>.push. > > Even if there are more, they are hardly interesting to StGIT, right? Not completely right. It is precisely remote.<branch>.fetch I'm needing, to be able to locate which remote a parent branch belongs to when creating a stack. It may be that the problem is git-remote being too limited, and if we implement the functionnality at that level, then maybe we can ignore those config settings. But maybe not, since I'd like stack creation to record a remote.<stack>.fetch entry. > So why not just pretend that they don't exist, by making a > dictionary, putting each new key/value pair into it one by one? > (Forgetting all but the last value for multi-values...) IMHO, that'd be the easiest way to shoot ourselves in the foot :) > > It would seem reasonable to start without a cache dictionnary, at least > > for now. After all, there are not so many config items to know about in > > a single stgit run, so IIMHO we're only going to notice a difference for > > the time needed to run the testsuite. > > The point is: it is very easy and short to just stash everything into a > dictionary, and retrieve it from there. OTOH, it is equally easy (if not easier) to call "git repo-config --get" or --get-all when needed :) Best regards, -- Yann. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html