Heya, On Sun, Aug 2, 2009 at 17:15, Shawn O. Pearce<spearce@xxxxxxxxxxx> wrote:> > Since you are changing the language format, please also update the > documentation of the language. Of course, but I wanted to know whether the change'd be accepted first :). > It might be cleaner to say "option foo=value\n" because then the > if block to parse the command line and the if block to parse the > input stream are the same. When parsing argv just skip the "--" > and pass the rest of the argv value into the function, when parsing > the stream, just skip the "option " and pass the rest of the line > into the function. sounds like a good idea, will do. > This has come up before on the list. We had somewhat decided against > setting options in the stream header. The only option class that > really impacts the data itself is the date format, all others > are about local file paths or how noisy the command should be. > Thus we decided that the frontend should invoke `git fast-import` > itself if it cared about these options, and that's what any typical > frontend does. Hmmm, yes, I guess that's possible, but that would require the frontend to shell out, whereas the option-based approach is easier to the user without requiring the frontend to know how to invoke git. And while the only option that impacts the data format is the date format, the import and export marks are very relevant when the frontend wants to do post-processing of the exported repository. I guess the question is, do we want to require frontends to create a wrapper around 'frontend | git fast-import --all-my=options', or is just "fronted | git fast-import" desirable enough that we want to allow this? -- Cheers, Sverre Rabbelier -- 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