git/Documentation/gitattributes.txt, branch v2.14.2

Merge branch 'ls/filter-process-delayed' into jt/subprocess-handshake

2017-07-26T19:56:19Z

* ls/filter-process-delayed: convert: add "status=delayed" to filter process protocol convert: refactor capabilities negotiation convert: move multiple file filter error handling to separate function convert: put the flags field before the flag itself for consistent style t0021: write "OUT " only on success t0021: make debug log file name configurable t0021: keep filter log files on comparison

convert: add "status=delayed" to filter process protocol

2017-06-30T20:50:41Z

Some `clean` / `smudge` filters may require a significant amount of time to process a single blob (e.g. the Git LFS smudge filter might perform network requests). During this process the Git checkout operation is blocked and Git needs to wait until the filter is done to continue with the checkout. Teach the filter process protocol, introduced in edcc8581 ("convert: add filter..process option", 2016-10-16), to accept the status "delayed" as response to a filter request. Upon this response Git continues with the checkout operation. After the checkout operation Git calls "finish_delayed_checkout" which queries the filter for remaining blobs. If the filter is still working on the completion, then the filter is expected to block. If the filter has completed all remaining blobs then an empty response is expected. Git has a multiple code paths that checkout a blob. Support delayed checkouts only in `clone` (in unpack-trees.c) and `checkout` operations for now. The optimization is most effective in these code paths as all files of the tree are processed. Signed-off-by: Lars Schneider Signed-off-by: Junio C Hamano

doc: do not use `rm .git/index` when normalizing line endings

2017-06-15T17:55:47Z

When illustrating how to normalize the line endings, the documentation in gitattributes tells the user to `rm .git/index`. This is incorrect for two reasons: - Users shouldn't be instructed to mess around with the internal implementation of Git using raw file system tools like `rm`. - Within a submodule or an additional working tree `.git` is just a file containing a `gitdir: ` pointer into the real `.git` directory. Therefore `rm .git/index` does not work. The purpose of the `rm .git/index` instruction is to remove all entries from the index without touching the working tree. The way to do this with Git is to use `read-tree --empty`. Signed-off-by: Andreas Heiduk Helped-by: Junio C Hamano Helped-by: Torsten Bögershausen Signed-off-by: Junio C Hamano

Merge branch 'tb/doc-eol-normalization'

2017-04-24T05:07:45Z

Doc update. * tb/doc-eol-normalization: gitattributes.txt: document how to normalize the line endings

gitattributes.txt: document how to normalize the line endings

2017-04-13T22:53:41Z

The instructions how to normalize the line endings should have been updated as part of commit 6523728499e 'convert: unify the "auto" handling of CRLF', (but that part never made it into the commit). Update the documentation in Documentation/gitattributes.txt and add a test case in t0025. Reported by Kristian Adrup https://github.com/git-for-windows/git/issues/954 Signed-off-by: Torsten Bögershausen Signed-off-by: Junio C Hamano

Documentation: fix a typo

2017-02-01T21:46:52Z

Signed-off-by: Stefan Beller Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

attr: support quoting pathname patterns in C style

2017-02-01T21:46:52Z

Full pattern must be quoted. So 'pat"t"ern attr' will give exactly 'pat"t"ern', not 'pattern'. Also clarify that leading whitespaces are not part of the pattern and document comment syntax. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano Signed-off-by: Stefan Beller Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

docs: warn about possible '=' in clean/smudge filter process values

2016-12-06T19:29:52Z

A pathname value in a clean/smudge filter process "key=value" pair can contain the '=' character (introduced in edcc858). Make the user aware of this issue in the docs, add a corresponding test case, and fix the issue in filter process value parser of the example implementation in contrib. Signed-off-by: Lars Schneider Signed-off-by: Junio C Hamano

contrib/long-running-filter: add long running filter example

2016-10-17T18:45:52Z

Add a simple pass-thru filter as example implementation for the Git filter protocol version 2. See Documentation/gitattributes.txt, section "Filter Protocol" for more info. Signed-off-by: Lars Schneider Signed-off-by: Junio C Hamano

convert: add filter..process option

2016-10-17T18:45:52Z

Git's clean/smudge mechanism invokes an external filter process for every single blob that is affected by a filter. If Git filters a lot of blobs then the startup time of the external filter processes can become a significant part of the overall Git execution time. In a preliminary performance test this developer used a clean/smudge filter written in golang to filter 12,000 files. This process took 364s with the existing filter mechanism and 5s with the new mechanism. See details here: https://github.com/github/git-lfs/pull/1382 This patch adds the `filter..process` string option which, if used, keeps the external filter process running and processes all blobs with the packet format (pkt-line) based protocol over standard input and standard output. The full protocol is explained in detail in `Documentation/gitattributes.txt`. A few key decisions: * The long running filter process is referred to as filter protocol version 2 because the existing single shot filter invocation is considered version 1. * Git sends a welcome message and expects a response right after the external filter process has started. This ensures that Git will not hang if a version 1 filter is incorrectly used with the filter..process option for version 2 filters. In addition, Git can detect this kind of error and warn the user. * The status of a filter operation (e.g. "success" or "error) is set before the actual response and (if necessary!) re-set after the response. The advantage of this two step status response is that if the filter detects an error early, then the filter can communicate this and Git does not even need to create structures to read the response. * All status responses are pkt-line lists terminated with a flush packet. This allows us to send other status fields with the same protocol in the future. Helped-by: Martin-Louis Bright Reviewed-by: Jakub Narebski Signed-off-by: Lars Schneider Signed-off-by: Junio C Hamano