On 8/22/2022 3:25 PM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> To allow for the incremental fetch case, teach Git to understand a >> bundle list that could be advertised at an independent bundle URI. Such >> a bundle list is likely to be inspected by human readers, even if only >> by the bundle provider creating the list. For this reason, we can take >> our expected "key=value" pairs and instead format them using Git config >> format. > > "can" does not explain why it is a good idea. "As a sequence of > key=value pairs is a lot more dense and harder to read than the > configuration file format, let's declare that it is the format we > use in a file that holds a bundle-list" would be. This "more dense and harder to read" was definitely my intention for wanting a different format. > I do not personally buy it, though. As I hinted in an earlier step, > some trait we associate with our configuration fioe format, like the > "last one wins" semantics, are undesirable ones, so even if we reuse > the appearance of the text, the semantics would have to become > different (including "syntax errors lead to die()" mentioned > elsewhere in the proposed log message). The points you made earlier about "last one wins" semantics are the biggest road-blocks to using the config file format, from what I've read so far. We could change those semantics to be different from my current implementation which respects the "last one wins" rule, and then that makes the config format match not as closely. That burden of avoiding multiple key values is not on the end-user but the bundle provider to match the new expectations. (There might be something we should be careful about when advertising the bundle list from our Git config in the 'bundle-uri' command in the next series.) The "syntax errors lead to die()" is mitigated by using CONFIG_ERROR_ERROR, which is what I meant by "Be careful to call..." I should have been more clear that we are _not_ going to die() based on the remote data. We might write an error message and then abort the bundle download. With all of these points in mind, I'd still prefer to use the config file format as described in the design document. If you still don't agree, then I'll change the format to be key=value pairs split with newlines, and update the design document accordingly. Thanks, -Stolee
