On Tue, Jan 18 2022, Neeraj Singh wrote: > Hi Ævar, > Could you please respond to the parent message? I did just now in https://lore.kernel.org/git/220119.8635ljoidt.gmgdl@xxxxxxxxxxxxxxxxxxx/; sorry about the delay. This thread fell off my radar. > To summarize the main points and questions: > 1) The current patch series design of core.fsync favors ease of > modification of the complete configuration as a single atomic config > step, at the cost of making it somewhat harder to derive a new > configuration from an existing one. See [1] where this facility is > used. > > 2) Is there any existing configuration that uses the multi-value > schema you proposed? The diff.wsErrorHighlight setting is actually > comma-separated. I replied to that. To add a bit to that the comma-delimited thing isn't any sort of a "blocker" or whatever in my mind. I just wanted to point out that you could get the same with multi-value with some better integration, and we might have our cake & eat it too. But at the end of the day if you disagree you're doing the work, and that's ultimately bikeshedding of the config interface. I'm fine with it either way. > 3) Is there any system you can point at or any support in the POSIX > spec for requiring fsync for anything other than durability of data > across system crash? Some examples in the linked... > 4) I think string_list_split_in_place is not valid for splitting a > comma-separated list in the config code, since the value coming from > the configset code is in some global data structure that might be used > again. It seems like we could have subtle problems down the line if we > mutate it. Replied to that too, hope it's all useful. Thanks again for working on this, it's really nice to have someone move the state of data integrity in git forward. > [1] https://github.com/neerajsi-msft/git/commit/7e9749a7e94d26c88789459588997329c5130792#diff-ee0307657f5a76b723c8973db0dbd5a2ca62e14b02711b897418b35d78fc6023R1327
