git/Documentation/git-range-diff.txt, branch gitk-resize-error

Merge branch 'js/range-diff-one-side-only'

2021-02-18T01:21:41Z

The "git range-diff" command learned "--(left|right)-only" option to show only one side of the compared range. * js/range-diff-one-side-only: range-diff: offer --left-only/--right-only options range-diff: move the diffopt initialization down one layer range-diff: combine all options in a single data structure range-diff: simplify code spawning `git log` range-diff: libify the read_patches() function again range-diff: avoid leaking memory in two error code paths

range-diff(docs): explain how to specify commit ranges

2021-02-07T05:24:55Z

There are three forms, depending whether the user specifies one, two or three non-option arguments. We've never actually explained how this works in the manual, so let's explain it. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

range-diff: offer --left-only/--right-only options

2021-02-07T05:14:31Z

When comparing commit ranges, one is frequently interested only in one side, such as asking the question "Has this patch that I submitted to the Git mailing list been applied?": one would only care about the part of the output that corresponds to the commits in a local branch. To make that possible, imitate the `git rev-list` options `--left-only` and `--right-only`. This addresses https://github.com/gitgitgadget/git/issues/206 Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'dl/range-diff-with-notes'

2019-12-05T20:52:44Z

"git range-diff" learned to take the "--notes=" and the "--no-notes" options to control the commit notes included in the log message that gets compared. * dl/range-diff-with-notes: format-patch: pass notes configuration to range-diff range-diff: pass through --notes to `git log` range-diff: output `## Notes ##` header t3206: range-diff compares logs with commit notes t3206: s/expected/expect/ t3206: disable parameter substitution in heredoc t3206: remove spaces after redirect operators pretty-options.txt: --notes accepts a ref instead of treeish rev-list-options.txt: remove reference to --show-notes argv-array: add space after `while`

range-diff: pass through --notes to `git log`

2019-11-21T00:29:52Z

When a commit being range-diff'd has a note attached to it, the note will be compared as well. However, if a user has multiple notes refs or if they want to suppress notes from being printed, there is currently no way to do this. Pass through `--[no-]notes[=]` to the `git log` call so that this option is customizable. Signed-off-by: Denton Liu Signed-off-by: Junio C Hamano

Documentation: fix a bunch of typos, both old and new

2019-11-07T04:42:00Z

Reported-by: Jens Schleusener Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

range-diff doc: add a section about output stability

2018-11-12T03:05:38Z

The range-diff command is already advertised as porcelain, but let's make it really clear that the output is completely subject to change, particularly when it comes to diff options such as --stat. Right now that option doesn't work, but fixing that is the subject of a later change. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

range-diff: use dim/bold cues to improve dual color mode

2018-08-13T17:44:52Z

It *is* a confusing thing to look at a diff of diffs. All too easy is it to mix up whether the -/+ markers refer to the "inner" or the "outer" diff, i.e. whether a `+` indicates that a line was added by either the old or the new diff (or both), or whether the new diff does something different than the old diff. To make things easier to process for normal developers, we introduced the dual color mode which colors the lines according to the commit diff, i.e. lines that are added by a commit (whether old, new, or both) are colored in green. In non-dual color mode, the lines would be colored according to the outer diff: if the old commit added a line, it would be colored red (because that line addition is only present in the first commit range that was specified on the command-line, i.e. the "old" commit, but not in the second commit range, i.e. the "new" commit). However, this dual color mode is still not making things clear enough, as we are looking at two levels of diffs, and we still only pick a color according to *one* of them (the outer diff marker is colored differently, of course, but in particular with deep indentation, it is easy to lose track of that outer diff marker's background color). Therefore, let's add another dimension to the mix. Still use green/red/normal according to the commit diffs, but now also dim the lines that were only in the old commit, and use bold face for the lines that are only in the new commit. That way, it is much easier not to lose track of, say, when we are looking at a line that was added in the previous iteration of a patch series but the new iteration adds a slightly different version: the obsolete change will be dimmed, the current version of the patch will be bold. At least this developer has a much easier time reading the range-diffs that way. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

range-diff: make --dual-color the default mode

2018-08-13T17:44:52Z

After using this command extensively for the last two months, this developer came to the conclusion that even if the dual color mode still leaves a lot of room for confusion about what was actually changed, the non-dual color mode is substantially worse in that regard. Therefore, we really want to make the dual color mode the default. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

range-diff: populate the man page

2018-08-13T17:44:51Z

The bulk of this patch consists of a heavily butchered version of tbdiff's README written by Thomas Rast and Thomas Gummerer, lifted from https://github.com/trast/tbdiff. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano