Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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. - 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
