git/contrib/completion, branch v2.35.2

Merge branch 'en/zdiff3'

2021-12-15T17:39:47Z

"Zealous diff3" style of merge conflict presentation has been added. * en/zdiff3: update documentation for new zdiff3 conflictStyle xdiff: implement a zealous diff3, or "zdiff3"

Merge branch 'yn/complete-date-format-options'

2021-12-10T22:35:15Z

The completion script (in contrib/) learns that the "--date" option of commands from the "git log" family takes "human" and "auto" as valid values. * yn/complete-date-format-options: completion: add human and auto: date format

xdiff: implement a zealous diff3, or "zdiff3"

2021-12-01T22:45:58Z

"zdiff3" is identical to ordinary diff3 except that it allows compaction of common lines on the two sides of history at the beginning or end of the conflict hunk. For example, the following diff3 conflict: 1 2 3 4 <<<<<< A B C D E |||||| 5 6 ====== A X C Y E >>>>>> 7 8 9 has common lines 'A', 'C', and 'E' on the two sides. With zdiff3, one would instead get the following conflict: 1 2 3 4 A <<<<<< B C D |||||| 5 6 ====== X C Y >>>>>> E 7 8 9 Note that the common lines, 'A', and 'E' were moved outside the conflict. Unlike with the two-way conflicts from the 'merge' conflictStyle, the zdiff3 conflict is NOT split into multiple conflict regions to allow the common 'C' lines to be shown outside a conflict, because zdiff3 shows the base version too and the base version cannot be reasonably split. Note also that the removing of lines common to the two sides might make the remaining text inside the conflict region match the base text inside the conflict region (for example, if the diff3 conflict had '5 6 E' on the right side of the conflict, then the common line 'E' would be moved outside and both the base and right side's remaining conflict text would be the lines '5' and '6'). This has the potential to surprise users and make them think there should not have been a conflict, but there definitely was a conflict and it should remain. Based-on-patch-by: Uwe Kleine-König Co-authored-by: Elijah Newren Signed-off-by: Phillip Wood Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

Merge branch 'tp/send-email-completion'

2021-11-29T23:41:49Z

The command line complation for "git send-email" options have been tweaked to make it easier to keep it in sync with the command itself. * tp/send-email-completion: send-email docs: add format-patch options send-email: programmatically generate bash completions

completion: add human and auto: date format

2021-11-26T06:09:46Z

human was introduced in acdd37769de8b0fe37a74bfc0475b63bdc55e9dc auto:* was introduced in 2fd7c22992d37469db957e9a4d3884a6c0a4d182 Those formats were missing when other values were added to completion at 5a59a2301f6ec9bcf1b101edb9ca33beb465842f Signed-off-by: Yoichi Nakayama Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 're/completion-fix-test-equality'

2021-10-29T22:43:16Z

Fix long-standing shell syntax error in the completion script. * re/completion-fix-test-equality: completion: fix incorrect bash/zsh string equality check

completion: fix incorrect bash/zsh string equality check

2021-10-28T16:33:19Z

In the basic `[`/`test` command, the string equality operator is a single `=`. The `==` operator is only available in `[[`, which is a bash-ism also supported by zsh. This mix-up was causing the following completion error in zsh: > __git_ls_files_helper:7: = not found (That message refers to the extraneous symbol in `==` ← `=`). This updates that comparison to use a single `=` inside the basic `[ … ]` test conditional. Although this fix is inconsistent with the other comparisons in this file, which use `[[ … == … ]]`, and the two expressions are functionally identical in this context, that approach was rejected due to a preference for `[`. Signed-off-by: Robert Estelle Signed-off-by: Junio C Hamano

send-email: programmatically generate bash completions

2021-10-28T16:04:24Z

"git send-email --git-completion-helper" only prints "format-patch" flags. Make it print "send-email" flags as well, extracting them programmatically from its three existing "GetOptions". Introduce a "uniq" subroutine, otherwise --cc-cover, --to-cover and other flags would show up twice. In addition, deduplicate flags common to both "send-email" and "format-patch", like --from. Remove extraneous flags: --h and --git-completion-helper. Add trailing "=" to options that expect an argument, inline with the format-patch implementation. Add a completion test for "send-email --validate", a send-email flag. Signed-off-by: Thiago Perrotta Based-on-patch-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'js/retire-preserve-merges'

2021-10-18T22:47:56Z

The "--preserve-merges" option of "git rebase" has been removed. * js/retire-preserve-merges: sequencer: restrict scope of a formerly public function rebase: remove a no-longer-used function rebase: stop mentioning the -p option in comments rebase: remove obsolete code comment rebase: drop the internal `rebase--interactive` command git-svn: drop support for `--preserve-merges` rebase: drop support for `--preserve-merges` pull: remove support for `--rebase=preserve` tests: stop testing `git rebase --preserve-merges` remote: warn about unhandled branch..rebase values t5520: do not use `pull.rebase=preserve`

Merge branch 'ti/tcsh-completion-regression-fix' into maint

2021-10-12T20:51:24Z

Update to the command line completion (in contrib/) for tcsh. * ti/tcsh-completion-regression-fix: completion: tcsh: Fix regression by drop of wrapper functions