W dniu 16.08.2016 o 14:36, Jeff King pisze: > What I think would be much more sane in general is to parse the whole > thing into a tree (or even a flat list of events), List of events is cheaper on memory (though I don't think there is an issue with size of config file), and can be turned into tree and DOM easily. > marking each > syntactically as a section header, a key, a comment, a run of > whitespace, and so on. And then do manipulations on that tree (e.g., > walk down to the section of interest, add a new key at the end), and > then reformat the tree back into a stream of bytes. That lets you > separate the policy logic from the parsing, and do high-level operations > that might involve multiple passes or backtracking in the tree (e.g., > walk to the section, walk past any existing keys, walk past any comments > but _not_ past any blank lines, then add the new key). > > There are other other upsides, too. For example, the current code cannot > write multiple unrelated keys in a single pass. > > The downsides is that it's a complete rewrite of the code. So it's a > _lot_ more work, and it carries more risk of regression. So please don't > take this as "no, your solution isn't OK; you have to do the rewrite". > We've been living with band-aids on the config code for a decade, so I > am OK with one more. So how 'git config --show-origin --list' works? Ah, I guess it prints as it goes, instead of parsing config file(s) into stream of events, and printing from those. -- Jakub Narębski -- 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