Re: [PATCH] fast-import: add ignore non-existent files option.

"Shawn O. Pearce" [off-list ref] writes:

Junio C Hamano [off-list ref] wrote:
...

quoted

I think selective loosening of consistency check makes sense very much,
but I have been wondering if these should be command line options.

The only example we saw so far is about output from one exporter.  Perhaps
it should be given to fast-import as initial set of commands ("#pragma"!)
that describes the nature of the input file?

Yea, I briefly considered that when I added the timestamp format
option.  I didn't bother because it was a single option and I figured
most frontends start git-fast-import directly.  But with this being
added a "format pragrma header thingy" makes a lot of sense.

Oh, I did not mean to suggest hiding it as a comment to silently allow
older fast-import slurp such input and produce broken results.

For input that needs such loosened error checking, old fast-import won't
produce correct results _anyway_, so I would agree that making these
things into explicit commands to cause older fast-import to error out
would make a lot more sense.

On Tue, Sep 2, 2008 at 10:36 AM, Junio C Hamano [off-list ref] wrote:

"Shawn O. Pearce" [off-list ref] writes:

quoted

Junio C Hamano [off-list ref] wrote:
...

quoted

I think selective loosening of consistency check makes sense very much,
but I have been wondering if these should be command line options.

The only example we saw so far is about output from one exporter.  Perhaps
it should be given to fast-import as initial set of commands ("#pragma"!)
that describes the nature of the input file?

Yea, I briefly considered that when I added the timestamp format
option.  I didn't bother because it was a single option and I figured
most frontends start git-fast-import directly.  But with this being
added a "format pragrma header thingy" makes a lot of sense.

Oh, I did not mean to suggest hiding it as a comment to silently allow
older fast-import slurp such input and produce broken results.

For input that needs such loosened error checking, old fast-import won't
produce correct results _anyway_, so I would agree that making these
things into explicit commands to cause older fast-import to error out
would make a lot more sense.

I like the idea. This way all the information to make it work is
already on the stream.

If the importer doesn't have a certain feature it can fail already at
initialization.

-- 
Felipe Contreras