Re: [RFC/PATCH 0/3] fast-import: give importers access to the object store

[Jonathan Nieder <jrnieder@gmail.com>]

Sverre Rabbelier wrote:
> On Fri, Sep 24, 2010 at 21:43, Jonathan Nieder <jrnieder@gmail.com> 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?