Re: fast-import and core.autocrlf option

["Shawn O. Pearce" <spearce@spearce.org>]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Right, in fast-import we only process blobs as raw blobs.
> > Its rare that we have a file path associated with the blob data
> > at the time that we are actually processing the blob itself.  E.g.
> > applications can send us blobs up front, before they even start to
> > send us commits and path information.
> 
> Don't the front-ends usually have path information already when
> they feed you a blob data, especially most of them operate on
> per-file history?  If that is the case,...

Depends.  A frontend can feed huge streams of blobs and use marks
to make us remember their SHA-1s, then later feed us those marks
and connect them to paths.  Such a frontend may not have exact path
information available when it feeds the blobs to us.  Then again
maybe it does.  Depends on how the source information was organized.

> > So if we were to offer the CRLF->LF conversion feature in fast-import
> > it would need to be an option supplied at the time the 'data'
> > command issued, rather than based upon the gitattributes system
> > that is normally used for working tree operations.
> 
> ... the "option" could be "this came from such and such path"
> instead of "this is DOS data, please apply crlf".

How do we setup .gitattributes?  Should it be read from a branch
in memory, or the working directory?

If it should be read from a branch, which branch?  What if the
frontend does not want the .gitattributes file in the history
of the import?  Putting it into a branch just to cause CRLF->LF
translation during import would require filter-branch afterwards
to strip out the file.

I'd rather make things very explicit.  If the frontend wants us to
apply a filter to a data chunk before we work further on it then
the frontend should give us the .gitattributes rules to apply as
part of the data command.

-- 
Shawn.