Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > The basic questions: > ... All good suggestions. > 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. A very good point again. I do not think anywhere in our codebase we use "|" as a separator for state files (either used for internal or exposed to the end user), and we probably would want to be consistent across commands. >> 4. New tests and documentation. There's really no end to this > > 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. Yes. > My main worry is still the commit messages. They don't need to be > elaborate but they should explain the purpose and effect of each > patch. Doubly yes. > I don't know how to move forward on that. I can explain what's > missing in each message, but I get the impression that you already > understand that and there's something else (e.g., time) preventing > them from getting fixed. Understanding that does not lead to an action does not really count, does it? After all, this series was labeled "for inclusion", not an RFC, which would mean the submitter, helpers, and reviewers all made reasonable effort to perfect the series to their ability, no? -- 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