On Fri, Aug 11, 2017 at 11:06 AM, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Aug 11, 2017 at 09:02:24AM +0200, Christian Couder wrote: > >> > But I really don't want callers to think of it as "unfold". I want it to >> > be "turn this into something I can parse simply". Hence if we were to >> > find another case where the output is irregular, I'd feel comfortable >> > calling that a bug and fixing it (one that I suspect but haven't tested >> > is that alternate separators probably should all be converted to >> > colons). >> >> Though "fixing" this after a release has been made might introduce a >> regression for people who would already use the option on trailers >> with different separators. That's also why I don't like --normalize. >> We just don't know if we will need to "fix" it a lot to make sure >> scripts using it will work in all cases. >> >> If we use --no-fold or --oneline instead, we don't promise too much >> from this option, so users cannot say that they expect it to work for >> them in all cases. > > But promising a normalized form is exactly what I want from the option. > > That said, I'm OK to promise that via "--parse", and call this --unfold, > if you really feel strongly. Yeah, I think promising these kind of things via an higher level option that is a shorthand for a mix of other basic options is much better especially if it's clearly documented that the option mix could change in case of bugs or improvements. This way people who want something stable, know that they should use their own mix of basic options. And those who are ok with something not as stable as long as it evolves towards a specific goal, know that they should use the higher level option.
