Hi Jeff, Junio, Jonathan, and Miles, Jeff King writes: > On Mon, Jul 11, 2011 at 01:07:20PM -0700, Junio C Hamano wrote: >> > 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. > > I had the same feeling about the "|". I'm a little confused about what > these options are good for, though. Miles Bader writes: > How about using "+" instead of "|"...? > > I think that would make sense both for bitfield-thinking and > non-bitfield-thinking readers ... :] Frankly, I don't like the idea of separate lines like "key = value1" and "key = value 2" -- even a generic *nix configuration file parser would break here. Yes, I know that we don't use "|" anywhere else; we don't persist options anywhere else either, so I was trying to be inventive :p I didn't realize "|" would confuse users -- if that's the case, should we use a different separator like Miles' "+" suggestion? Jeff King writes: > Is it purely about saving some persistent data between runs, and nobody > else is going to look at it? In that case, I don't think it matters what > the format is. Use some unambiguous encoding that we already have > available (like sq_quote_argv and sq_dequote_argv), and write as little > code as possible. > > Or is it something that, like the information in .git/rebase-apply, > people might want to read or tweak? In that case, might it make sense to > follow that lead and split things into one file per item? That keeps the > parsing burden extremely low for things like shell scripts (or shell > users) who might want to read or tweak. Yes, it's a little like the information in .git/rebase-apply. We should give the user the ability to tweak it by hand: the result from sq_quote_argv and sq_dequote_argv would look very ugly. Hm, I don't like the one-file-per-command-line-option approach because: we might only have a few options now, but when the sequencer is built to support many actions and options, the directory will be polluted with lots of files. I was thinking more along the lines of something that can be parsed using gitconfig. Thanks. -- Ram -- 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