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

Merge branch 'jk/attributes-path-doc'

2018-03-21T18:30:15Z

Doc update. * jk/attributes-path-doc: doc/gitattributes: mention non-recursive behavior

doc/gitattributes: mention non-recursive behavior

2018-03-20T17:01:03Z

The gitattributes documentation claims that the pattern rules are largely the same as for gitignore. However, the rules for recursion are different. In an ideal world, we would make them the same (if for nothing else than consistency and simplicity), but that would create backwards compatibility issues. For some discussion, see this thread: https://public-inbox.org/git/slrnkldd3g.1l4.jan@majutsushi.net/ But let's at least document the differences instead of actively misleading the user by claiming that they're the same. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

userdiff: add built-in pattern for golang

2018-03-01T21:36:49Z

This adds xfuncname and word_regex patterns for golang, a quite popular programming language. It also includes test cases for the xfuncname regex (t4018) and updated documentation. The xfuncname regex finds functions, structs and interfaces. Although the Go language prohibits the opening brace from being on its own line, the regex does not makes it mandatory, to be able to match `func` statements like this: func foo(bar int, baz int) { } This is covered by the test case t4018/golang-long-func. The word_regex pattern finds identifiers, integers, floats, complex numbers and operators, according to the go specification. Signed-off-by: Alban Gruin Signed-off-by: Junio C Hamano

Docs: split out long-running subprocess handshake

2018-01-25T19:24:32Z

Separating out the implementation of the handshake when starting a long-running subprocess (for example, as is done for a clean/smudge filter) was done in commit fa64a2fdbeed ("sub-process: refactor handshake to common function", 2017-07-26), but its documentation still resides in gitattributes. Split out the documentation as well. Signed-off-by: Jonathan Tan Signed-off-by: Junio C Hamano

add: introduce "--renormalize"

2017-11-17T01:31:05Z

Make it safer to normalize the line endings in a repository. Files that had been commited with CRLF will be commited with LF. The old way to normalize a repo was like this: # Make sure that there are not untracked files $ echo "* text=auto" >.gitattributes $ git read-tree --empty $ git add . $ git commit -m "Introduce end-of-line normalization" The user must make sure that there are no untracked files, otherwise they would have been added and tracked from now on. The new "add --renormalize" does not add untracked files: $ echo "* text=auto" >.gitattributes $ git add --renormalize . $ git commit -m "Introduce end-of-line normalization" Note that "git add --renormalize " is the short form for "git add -u --renormalize ". While at it, document that the same renormalization may be needed, whenever a clean filter is added or changed. Helped-By: Junio C Hamano Signed-off-by: Torsten Bögershausen Signed-off-by: Junio C Hamano

Documentation: mention that `eol` can change the dirty status of paths

2017-09-06T23:57:54Z

When setting the `eol` attribute, paths can change their dirty status without any change in the working directory. This can cause confusion and should at least be mentioned with a remedy. Signed-off-by: Ben Boeckel Reviewed-by: Torsten Bögershausen Signed-off-by: Junio C Hamano

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