Junio C Hamano <gitster@xxxxxxxxx> writes: > "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. > > 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). One reason for using the configuration file format (which perhaps could have been better explained in the commit message) is that we plan to have a way for a repo to advertise a list of bundles during fetch. I think that config is a natural place to put that, even with its "last one wins" semantics. It could be argued that we can just put a single URI in config and only allow advertising of a single URI (and then use a different format for the bundle lists with semantics that are stricter than "last one wins"), but that seems unnecessarily restrictive (and would make the client make one more network request). And if we're advertising multiple bundles, it seems reasonable to make all bundle lists have the same format (whether they are in config or in a separate file).
