git/Documentation/diff-options.txt, branch v2.42.2

Merge branch 'so/diff-doc-for-patch-update' into maint-2.42

2023-11-02T07:53:17Z

References from description of the `--patch` option in various manual pages have been simplified and improved. * so/diff-doc-for-patch-update: doc/diff-options: fix link to generating patch section

doc/diff-options: fix link to generating patch section

2023-09-06T15:58:45Z

When formatted as man-page, the section title is rendered "GENERATING PATCH TEXT WITH -P" whereas reference still reads "Generating patch text with -p", that is inconsistent and makes searching harder than it needs to be. Fix this by getting rid of custom reference text. Also, documentation for every command that describes `-p` option by including the "diff-options.txt" file does include the "diff-generate-patch.txt" file as well (as it should), so the internal link is in fact useful for any of them. Fix this by getting rid of conditionals around the reference. Fixes: ebdc46c242 (docs: link generating patch sections) Signed-off-by: Sergey Organov Signed-off-by: Junio C Hamano

Merge branch 'jc/diff-s-with-other-options'

2023-06-13T19:29:45Z

The "-s" (silent, squelch) option of the "diff" family of commands did not interact with other options that specify the output format well. This has been cleaned up so that it will clear all the formatting options given before. * jc/diff-s-with-other-options: diff: fix interaction between the "-s" option and other options

diff: fix interaction between the "-s" option and other options

2023-05-05T21:24:32Z

Sergey Organov noticed and reported "--patch --no-patch --raw" behaves differently from just "--raw". It turns out that there are a few interesting bugs in the implementation and documentation. * First, the documentation for "--no-patch" was unclear that it could be read to mean "--no-patch" countermands an earlier "--patch" but not other things. The intention of "--no-patch" ever since it was introduced at d09cd15d (diff: allow --no-patch as synonym for -s, 2013-07-16) was to serve as a synonym for "-s", so "--raw --patch --no-patch" should have produced no output, but it can be (mis)read to allow showing only "--raw" output. * Then the interaction between "-s" and other format options were poorly implemented. Modern versions of Git uses one bit each to represent formatting options like "--patch", "--stat" in a single output_format word, but for historical reasons, "-s" also is represented as another bit in the same word. This allows two interesting bugs to happen, and we have both X-<. (1) After setting a format bit, then setting NO_OUTPUT with "-s", the code to process another "--" option drops the NO_OUTPUT bit to allow output to be shown again. However, the code to handle "-s" only set NO_OUTPUT without unsetting format bits set earlier, so the earlier format bit got revealed upon seeing the second "--" option. This is the problem Sergey observed. (2) After setting NO_OUTPUT with "-s", code to process "--" option can forget to unset NO_OUTPUT, leaving the command still silent. It is tempting to change the meaning of "--no-patch" to mean "disable only the patch format output" and reimplement "-s" as "not showing anything", but it would be an end-user visible change in behavior. Let's fix the interactions of these bits to first make "-s" work as intended. The fix is conceptually very simple. * Whenever we set DIFF_FORMAT_FOO because we saw the "--foo" option (e.g. DIFF_FORMAT_RAW is set when the "--raw" option is given), we make sure we drop DIFF_FORMAT_NO_OUTPUT. We forgot to do so in some of the options and caused (2) above. * When processing "-s" option, we should not just set DIFF_FORMAT_NO_OUTPUT bit, but clear other DIFF_FORMAT_* bits. We didn't do so and retained format bits set by options previously seen, causing (1) above. It is even more tempting to lose NO_OUTPUT bit and instead take output_format word being 0 as its replacement, but that would break the mechanism "git show" uses to default to "--patch" output, where the distinction between telling the command to be silent with "-s" and having no output format specified on the command line matters, and an explicit output format given on the command line should not be "combined" with the default "--patch" format. So, while we cannot lose the NO_OUTPUT bit, as a follow-up work, we may want to replace it with OPTION_GIVEN bit, and * make "--patch", "--raw", etc. set DIFF_FORMAT_$format bit and DIFF_FORMAT_OPTION_GIVEN bit on for each format. "--no-raw", etc. will set off DIFF_FORMAT_$format bit but still record the fact that we saw an option from the command line by setting DIFF_FORMAT_OPTION_GIVEN bit. * make "-s" (and its synonym "--no-patch") clear all other bits and set only the DIFF_FORMAT_OPTION_GIVEN bit on. which I suspect would make the code much cleaner without breaking any end-user expectations. Once that is in place, transitioning "--no-patch" to mean the counterpart of "--patch", just like "--no-raw" only defeats an earlier "--raw", would be quite simple at the code level. The social cost of migrating the end-user expectations might be too great for it to be worth, but at least the "GIVEN" bit clean-up alone may be worth it. Signed-off-by: Junio C Hamano

diff: add --default-prefix option

2023-03-09T16:32:21Z

You can change the output of prefixes with diff.noprefix and diff.mnemonicprefix, but there's no easy way to override them from the command-line. We do have "--no-prefix", but there's no way to get back to the default prefix. So let's add an option to do that. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

docs: link generating patch sections

2023-01-13T20:55:14Z

Currently, in the git-log documentation, the reference to generating patches does not match the section title. This can make the section "Generating patch text with -p" hard to find, since typically readers of the documentation will copy and paste to search the page. Let's make this more convenient for readers by linking it directly to the section. Since git-log pulls in diff-generate-patch.txt, we can provide a direct link to the section. Otherwise, change the verbiage to match exactly what the section title is, to at least make searching for it an easier task. Signed-off-by: John Cai Signed-off-by: Junio C Hamano

Merge branch 'js/diff-filter-negation-fix'

2022-02-16T23:14:30Z

"git diff --diff-filter=aR" is now parsed correctly. * js/diff-filter-negation-fix: diff-filter: be more careful when looking for negative bits diff.c: move the diff filter bits definitions up a bit docs(diff): lose incorrect claim about `diff-files --diff-filter=A`

show, log: provide a --remerge-diff capability

2022-02-02T18:02:27Z

When this option is specified, we remerge all (two parent) merge commits and diff the actual merge commit to the automatically created version, in order to show how users removed conflict markers, resolved the different conflict versions, and potentially added new changes outside of conflict regions in order to resolve semantic merge problems (or, possibly, just to hide other random changes). This capability works by creating a temporary object directory and marking it as the primary object store. This makes it so that any blobs or trees created during the automatic merge are easily removable afterwards by just deleting all objects from the temporary object directory. There are a few ways that this implementation is suboptimal: * `log --remerge-diff` becomes slow, because the temporary object directory can fill with many loose objects while running * the log output can be muddied with misplaced "warning: cannot merge binary files" messages, since ll-merge.c unconditionally writes those messages to stderr while running instead of allowing callers to manage them. * important conflict and warning messages are simply dropped; thus for conflicts like modify/delete or rename/rename or file/directory which are not representable with content conflict markers, there may be no way for a user of --remerge-diff to know that there had been a conflict which was resolved (and which possibly motivated other changes in the merge commit). * when fixing the previous issue, note that some unimportant conflict and warning messages might start being included. We should instead make sure these remain dropped. Subsequent commits will address these issues. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

docs(diff): lose incorrect claim about `diff-files --diff-filter=A`

2022-01-28T18:18:17Z

Originally, before we had `--intent-to-add`, there was no way that `git diff-files` could see added files: if a file did not exist in the index, `git diff-files` would not show it because it looks only at worktree files when there is an index entry at the same path. We used this example in the documentation of the diff options to explain that not every `--diff-filter=

Merge branch 'jn/log-m-does-not-imply-p'

2021-08-11T19:36:18Z

Earlier "git log -m" was changed to always produce patch output, which would break existing scripts, which has been reverted. * jn/log-m-does-not-imply-p: Revert 'diff-merges: let "-m" imply "-p"'