diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/RelNotes/2.14.2.txt | 35 | ||||
| -rw-r--r-- | Documentation/config.txt | 10 | ||||
| -rw-r--r-- | Documentation/diff-config.txt | 11 | ||||
| -rw-r--r-- | Documentation/diff-options.txt | 17 | ||||
| -rw-r--r-- | Documentation/git-for-each-ref.txt | 6 | ||||
| -rw-r--r-- | Documentation/git-merge.txt | 5 | ||||
| -rw-r--r-- | Documentation/git-tag.txt | 3 | ||||
| -rw-r--r-- | Documentation/git.txt | 3 | ||||
| -rw-r--r-- | Documentation/gitattributes.txt | 69 | ||||
| -rw-r--r-- | Documentation/pretty-formats.txt | 18 | ||||
| -rw-r--r-- | Documentation/technical/api-builtin.txt | 73 | ||||
| -rw-r--r-- | Documentation/technical/api-sub-process.txt | 59 |
12 files changed, 144 insertions, 165 deletions
diff --git a/Documentation/RelNotes/2.14.2.txt b/Documentation/RelNotes/2.14.2.txt new file mode 100644 index 0000000000..5517afcf59 --- /dev/null +++ b/Documentation/RelNotes/2.14.2.txt @@ -0,0 +1,35 @@ +Git v2.14.2 Release Notes +========================= + +Fixes since v2.14.1 +------------------- + + * Because recent Git for Windows do come with a real msgfmt, the + build procedure for git-gui has been updated to use it instead of a + hand-rolled substitute. + + * "%C(color name)" in the pretty print format always produced ANSI + color escape codes, which was an early design mistake. They now + honor the configuration (e.g. "color.ui = never") and also tty-ness + of the output medium. + + * The http.{sslkey,sslCert} configuration variables are to be + interpreted as a pathname that honors "~[username]/" prefix, but + weren't, which has been fixed. + + * Numerous bugs in walking of reflogs via "log -g" and friends have + been fixed. + + * "git commit" when seeing an totally empty message said "you did not + edit the message", which is clearly wrong. The message has been + corrected. + + * When a directory is not readable, "gitweb" fails to build the + project list. Work this around by skipping such a directory. + + * A recently added test for the "credential-cache" helper revealed + that EOF detection done around the time the connection to the cache + daemon is torn down were flaky. This was fixed by reacting to + ECONNRESET and behaving as if we got an EOF. + +Also contains various documentation updates and code clean-ups. diff --git a/Documentation/config.txt b/Documentation/config.txt index d5c9c4cab6..478b9431e0 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -216,15 +216,15 @@ boolean:: synonyms are accepted for 'true' and 'false'; these are all case-insensitive. - true;; Boolean true can be spelled as `yes`, `on`, `true`, - or `1`. Also, a variable defined without `= <value>` + true;; Boolean true literals are `yes`, `on`, `true`, + and `1`. Also, a variable defined without `= <value>` is taken as true. - false;; Boolean false can be spelled as `no`, `off`, - `false`, or `0`. + false;; Boolean false literals are `no`, `off`, `false`, + `0` and the empty string. + When converting value to the canonical form using `--bool` type -specifier; 'git config' will ensure that the output is "true" or +specifier, 'git config' will ensure that the output is "true" or "false" (spelled in lowercase). integer:: diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt index cbce8ec638..5ca942ab5e 100644 --- a/Documentation/diff-config.txt +++ b/Documentation/diff-config.txt @@ -200,7 +200,10 @@ diff.algorithm:: + diff.wsErrorHighlight:: - A comma separated list of `old`, `new`, `context`, that - specifies how whitespace errors on lines are highlighted - with `color.diff.whitespace`. Can be overridden by the - command line option `--ws-error-highlight=<kind>` + Highlight whitespace errors in the `context`, `old` or `new` + lines of the diff. Multiple values are separated by comma, + `none` resets previous values, `default` reset the list to + `new` and `all` is a shorthand for `old,new,context`. The + whitespace errors are colored with `color.diff.whitespace`. + The command line option `--ws-error-highlight=<kind>` + overrides this setting. diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 43d18a4c5c..56dedafcd4 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -300,15 +300,14 @@ ifndef::git-format-patch[] with --exit-code. --ws-error-highlight=<kind>:: - Highlight whitespace errors on lines specified by <kind> - in the color specified by `color.diff.whitespace`. <kind> - is a comma separated list of `old`, `new`, `context`. When - this option is not given, only whitespace errors in `new` - lines are highlighted. E.g. `--ws-error-highlight=new,old` - highlights whitespace errors on both deleted and added lines. - `all` can be used as a short-hand for `old,new,context`. - The `diff.wsErrorHighlight` configuration variable can be - used to specify the default behaviour. + Highlight whitespace errors in the `context`, `old` or `new` + lines of the diff. Multiple values are separated by comma, + `none` resets previous values, `default` reset the list to + `new` and `all` is a shorthand for `old,new,context`. When + this option is not given, and the configuration variable + `diff.wsErrorHighlight` is not set, only whitespace errors in + `new` lines are highlighted. The whitespace errors are colored + whith `color.diff.whitespace`. endif::git-format-patch[] diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index e8772e532c..bb370c9c7b 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -157,8 +157,10 @@ HEAD:: otherwise. color:: - Change output color. Followed by `:<colorname>`, where names - are described in `color.branch.*`. + Change output color. Followed by `:<colorname>`, where color + names are described under Values in the "CONFIGURATION FILE" + section of linkgit:git-config[1]. For example, + `%(color:bold red)`. align:: Left-, middle-, or right-align the content between diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index 04fdd8cf08..f90faf7aaa 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -280,7 +280,10 @@ After seeing a conflict, you can do two things: * Resolve the conflicts. Git will mark the conflicts in the working tree. Edit the files into shape and - 'git add' them to the index. Use 'git commit' to seal the deal. + 'git add' them to the index. Use 'git commit' or + 'git merge --continue' to seal the deal. The latter command + checks whether there is a (interrupted) merge in progress + before calling 'git commit'. You can work through the conflict with a number of tools: diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 32410f3d22..543fb425ee 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -205,6 +205,9 @@ it in the repository configuration as follows: signingKey = <gpg-keyid> ------------------------------------- +`pager.tag` is only respected when listing tags, i.e., when `-l` is +used or implied. The default is to use a pager. +See linkgit:git-config[1]. DISCUSSION ---------- diff --git a/Documentation/git.txt b/Documentation/git.txt index 7dd5e03280..6e3a6767e5 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -75,7 +75,8 @@ example the following invocations are equivalent: Note that omitting the `=` in `git -c foo.bar ...` is allowed and sets `foo.bar` to the boolean true value (just like `[foo]bar` would in a config file). Including the equals but with an empty value (like `git -c -foo.bar= ...`) sets `foo.bar` to the empty string. +foo.bar= ...`) sets `foo.bar` to the empty string which ` git config +--bool` will convert to `false`. --exec-path[=<path>]:: Path to wherever your core Git programs are installed. diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 2a2d7e2a4d..c4f2be2542 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -425,8 +425,8 @@ packet: git< capability=clean packet: git< capability=smudge packet: git< 0000 ------------------------ -Supported filter capabilities in version 2 are "clean" and -"smudge". +Supported filter capabilities in version 2 are "clean", "smudge", +and "delay". Afterwards Git sends a list of "key=value" pairs terminated with a flush packet. The list will contain at least the filter command @@ -512,12 +512,73 @@ the protocol then Git will stop the filter process and restart it with the next file that needs to be processed. Depending on the `filter.<driver>.required` flag Git will interpret that as error. -After the filter has processed a blob it is expected to wait for -the next "key=value" list containing a command. Git will close +After the filter has processed a command it is expected to wait for +a "key=value" list containing the next command. Git will close the command pipe on exit. The filter is expected to detect EOF and exit gracefully on its own. Git will wait until the filter process has stopped. +Delay +^^^^^ + +If the filter supports the "delay" capability, then Git can send the +flag "can-delay" after the filter command and pathname. This flag +denotes that the filter can delay filtering the current blob (e.g. to +compensate network latencies) by responding with no content but with +the status "delayed" and a flush packet. +------------------------ +packet: git> command=smudge +packet: git> pathname=path/testfile.dat +packet: git> can-delay=1 +packet: git> 0000 +packet: git> CONTENT +packet: git> 0000 +packet: git< status=delayed +packet: git< 0000 +------------------------ + +If the filter supports the "delay" capability then it must support the +"list_available_blobs" command. If Git sends this command, then the +filter is expected to return a list of pathnames representing blobs +that have been delayed earlier and are now available. +The list must be terminated with a flush packet followed +by a "success" status that is also terminated with a flush packet. If +no blobs for the delayed paths are available, yet, then the filter is +expected to block the response until at least one blob becomes +available. The filter can tell Git that it has no more delayed blobs +by sending an empty list. As soon as the filter responds with an empty +list, Git stops asking. All blobs that Git has not received at this +point are considered missing and will result in an error. + +------------------------ +packet: git> command=list_available_blobs +packet: git> 0000 +packet: git< pathname=path/testfile.dat +packet: git< pathname=path/otherfile.dat +packet: git< 0000 +packet: git< status=success +packet: git< 0000 +------------------------ + +After Git received the pathnames, it will request the corresponding +blobs again. These requests contain a pathname and an empty content +section. The filter is expected to respond with the smudged content +in the usual way as explained above. +------------------------ +packet: git> command=smudge +packet: git> pathname=path/testfile.dat +packet: git> 0000 +packet: git> 0000 # empty content! +packet: git< status=success +packet: git< 0000 +packet: git< SMUDGED_CONTENT +packet: git< 0000 +packet: git< 0000 # empty list, keep "status=success" unchanged! +------------------------ + +Example +^^^^^^^ + A long running filter demo implementation can be found in `contrib/long-running-filter/example.pl` located in the Git core repository. If you develop your own long running filter diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index 4d6dac5770..973d19606b 100644 --- a/Documentation/pretty-formats.txt +++ b/Documentation/pretty-formats.txt @@ -173,13 +173,17 @@ endif::git-rev-list[] - '%Cblue': switch color to blue - '%Creset': reset color - '%C(...)': color specification, as described under Values in the - "CONFIGURATION FILE" section of linkgit:git-config[1]; - adding `auto,` at the beginning (e.g. `%C(auto,red)`) will emit - color only when colors are enabled for log output (by `color.diff`, - `color.ui`, or `--color`, and respecting the `auto` settings of the - former if we are going to a terminal). `auto` alone (i.e. - `%C(auto)`) will turn on auto coloring on the next placeholders - until the color is switched again. + "CONFIGURATION FILE" section of linkgit:git-config[1]. + By default, colors are shown only when enabled for log output (by + `color.diff`, `color.ui`, or `--color`, and respecting the `auto` + settings of the former if we are going to a terminal). `%C(auto,...)` + is accepted as a historical synonym for the default (e.g., + `%C(auto,red)`). Specifying `%C(always,...) will show the colors + even when color is not otherwise enabled (though consider + just using `--color=always` to enable color for the whole output, + including this format and anything else git might color). `auto` + alone (i.e. `%C(auto)`) will turn on auto coloring on the next + placeholders until the color is switched again. - '%m': left (`<`), right (`>`) or boundary (`-`) mark - '%n': newline - '%%': a raw '%' diff --git a/Documentation/technical/api-builtin.txt b/Documentation/technical/api-builtin.txt deleted file mode 100644 index 22a39b9299..0000000000 --- a/Documentation/technical/api-builtin.txt +++ /dev/null @@ -1,73 +0,0 @@ -builtin API -=========== - -Adding a new built-in ---------------------- - -There are 4 things to do to add a built-in command implementation to -Git: - -. Define the implementation of the built-in command `foo` with - signature: - - int cmd_foo(int argc, const char **argv, const char *prefix); - -. Add the external declaration for the function to `builtin.h`. - -. Add the command to the `commands[]` table defined in `git.c`. - The entry should look like: - - { "foo", cmd_foo, <options> }, -+ -where options is the bitwise-or of: - -`RUN_SETUP`:: - If there is not a Git directory to work on, abort. If there - is a work tree, chdir to the top of it if the command was - invoked in a subdirectory. If there is no work tree, no - chdir() is done. - -`RUN_SETUP_GENTLY`:: - If there is a Git directory, chdir as per RUN_SETUP, otherwise, - don't chdir anywhere. - -`USE_PAGER`:: - - If the standard output is connected to a tty, spawn a pager and - feed our output to it. - -`NEED_WORK_TREE`:: - - Make sure there is a work tree, i.e. the command cannot act - on bare repositories. - This only makes sense when `RUN_SETUP` is also set. - -. Add `builtin/foo.o` to `BUILTIN_OBJS` in `Makefile`. - -Additionally, if `foo` is a new command, there are 3 more things to do: - -. Add tests to `t/` directory. - -. Write documentation in `Documentation/git-foo.txt`. - -. Add an entry for `git-foo` to `command-list.txt`. - -. Add an entry for `/git-foo` to `.gitignore`. - - -How a built-in is called ------------------------- - -The implementation `cmd_foo()` takes three parameters, `argc`, `argv, -and `prefix`. The first two are similar to what `main()` of a -standalone command would be called with. - -When `RUN_SETUP` is specified in the `commands[]` table, and when you -were started from a subdirectory of the work tree, `cmd_foo()` is called -after chdir(2) to the top of the work tree, and `prefix` gets the path -to the subdirectory the command started from. This allows you to -convert a user-supplied pathname (typically relative to that directory) -to a pathname relative to the top of the work tree. - -The return value from `cmd_foo()` becomes the exit status of the -command. diff --git a/Documentation/technical/api-sub-process.txt b/Documentation/technical/api-sub-process.txt deleted file mode 100644 index 793508cf3e..0000000000 --- a/Documentation/technical/api-sub-process.txt +++ /dev/null @@ -1,59 +0,0 @@ -sub-process API -=============== - -The sub-process API makes it possible to run background sub-processes -for the entire lifetime of a Git invocation. If Git needs to communicate -with an external process multiple times, then this can reduces the process -invocation overhead. Git and the sub-process communicate through stdin and -stdout. - -The sub-processes are kept in a hashmap by command name and looked up -via the subprocess_find_entry function. If an existing instance can not -be found then a new process should be created and started. When the -parent git command terminates, all sub-processes are also terminated. - -This API is based on the run-command API. - -Data structures ---------------- - -* `struct subprocess_entry` - -The sub-process structure. Members should not be accessed directly. - -Types ------ - -'int(*subprocess_start_fn)(struct subprocess_entry *entry)':: - - User-supplied function to initialize the sub-process. This is - typically used to negotiate the interface version and capabilities. - - -Functions ---------- - -`cmd2process_cmp`:: - - Function to test two subprocess hashmap entries for equality. - -`subprocess_start`:: - - Start a subprocess and add it to the subprocess hashmap. - -`subprocess_stop`:: - - Kill a subprocess and remove it from the subprocess hashmap. - -`subprocess_find_entry`:: - - Find a subprocess in the subprocess hashmap. - -`subprocess_get_child_process`:: - - Get the underlying `struct child_process` from a subprocess. - -`subprocess_read_status`:: - - Helper function to read packets looking for the last "status=<foo>" - key/value pair. |