Ramkumar Ramachandra wrote: > Jonathan Nieder writes: >> To be precise, the format used includes >> >> strategy-option = patience | renormalize >> >> to represent the effect of "-Xpatience -Xrenormalize". My only worry >> about that is that the "|" can sound like "or", which would seem >> strange to a user that does not necessarily develop software (so is >> not thinking about bitfields). The format used in config files puts >> >> strategy-option = patience >> strategy-option = renormalize >> >> as separate lines. > > Okay, I can change to that if it's desirable. My rationale for using > "|" is that lines like "key = value1" and "key = value2" tend to look > odd -- it's like I'm reassigning the key a different value. On second thought, I don't think it matters, since this is not meant for humans anyway, right? I.e., it could be gibberish=patience renormalize and that would work just as well. Feel free to forget I said anything. >> Once each new feature has been documented and each new feature or >> fixed bug has an associated test, you've reached the end of this. > > It depends on how rigorously you want to document and test things, no? > For example, I haven't documented the formats of the configuration > files anywhere but in the commit messages. Something in > Documentation/technical would be nice, but I think we should wait > until the format evolves a bit. Since I haven't exposed anything like > a "--interactive" functionality, the user will never see it and we can > change it as and when we like. Right, I haven't looked through carefully but this didn't look underdocumented. I mostly meant about tests: > Also, for things like the option parser, how far do you want to go > with testing? How many kinds of malformed instruction sheets do you > want to test with? I'll include some more basic tests soon, but I > don't think we should go too deep, due to time constraints. There are other reasons not to test too much, too: the longer tests are, the less pleasant an experience it is to run them or to modify the testsuite later. So just the minimum to make sure the feature and checks you carefully introduced continue to work as later changes are made is not only enough but ideal. > I have updated many of the commit messages. Do let me know what's > missing where. Will send relevant links to previous reviews. Thanks. -- 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