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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sep 25, 2010, 00:01 UTC
Message-ID: <20100925000156.GA23735@burratino>
In-Reply-To: <AANLkTinsotbGpg1LAXA+UchBHQrBK12tkX+o4tOFWUOF@mail.gmail.com>

Sverre Rabbelier wrote:

> On Fri, Sep 24, 2010 at 21:43, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 6 quoted lines

>> 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. :)

Show 8 quoted lines

>> 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?