Sverre Rabbelier wrote: > On Fri, Sep 24, 2010 at 21:43, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> Yes, I guess "feature report-fd=3" is a protocol layering violation. >> Unfortunately import-marks and export-marks have already set a >> precedent. > > I don't agree, they (can) use a relative path name, allow the stream > to be re-used at a different location. Sorry, I had confused myself. Especially with relative-marks, using relative paths without worrying about where they point makes a lot of sense. I was thinking of a frontend that reads or writes the marks file itself, but import/export-marks features can also be used to just save/restore marks opaquely. (So iiuc one could imagine a backend that writes the marks within a table somewhere instead of a text file when relative-marks is requested, and most frontends could cope with that.) Thus I have no precedent to fall back on. :) >> Well-behaved streams could use that and rely on the fd to be set on >> the command line, while poorly-behaved streams could still use >> "feature report-fd=whatever" to get the effect of --report-fd=whatever >> and avoid breaking UI consistency. > > Additionally you could have the commandline override whatever the > stream sets, so that the stream can be re-used as long as the user > specifies the appropriate commandline arguments? Yep, that would work. Still I don't think it makes a lot of sense to allow "feature report-fd=4" in the fast-import stream. If I can ensure that fast-import has file descriptor 4 mapped to the right place, then I am in control of the process that starts fast-import, so a command-line option would be easy enough to use, 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