Stefan Beller <sbeller@xxxxxxxxxx> writes: > It turns out it doesn't quite do that; > The parsing code takes the old notation into account and translates any > [V.A] > r = ... > into a lower cased "v.a." for ease of comparison. That happens in > get_base_var, which would call further into get_extended_base_var > if the new notation is used. > > The code in store_aux_event however is written without the consideration > of the old code and has no way of knowing the capitalization of the > section or subsection (which were forced to lowercase in the old > dot notation). > > So either we have to do some major surgery, or the old notation gets > some regression while fixing the new notation. As long as - the regression is documented clearly (i.e. what unexpected thing happens, just like you have a good description in the log message of PATCH 2/3 for "[foo "Bar"] key = ..."), - users are nudged to use the new style instead, and - writing with "git config" (or "git init/clone" for that matter) won't produce these old-style sections I think it is OK to punt. I would expect, as Git's userbase is a lot wider than 10 years ago, there is at least some people who did exploit the fact that "[V.A] r = one" and "[v.a] r = two" give a single "v.a.r" variable that is multi-valued, and it indeed would be a regression to them, to which no good workaround exists. But breaking '[V "a"] r = ...' is a more grave sin. Even though I hate to rob Peter to pay Paul (or vice versa), in this case it is justified to fix the more basic form sooner and wait for an actual complaint before fixing the new and deliberate regression introduced while fixing it to the old-style variable.
