git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Fernando Ramos <greenfoo@u92.eu>
Cc: git@vger.kernel.org, davvid@gmail.com, sunshine@sunshineco.com,
	seth@eseth.com, levraiphilippeblain@gmail.com,
	rogi@skylittlesystem.org
Subject: Re: [PATCH v5 1/3] vimdiff: new implementation with layout support
Date: Wed, 23 Mar 2022 09:43:34 -0700	[thread overview]
Message-ID: <xmqqsfr8sjpl.fsf@gitster.g> (raw)
In-Reply-To: <20220319091141.4911-2-greenfoo@u92.eu> (Fernando Ramos's message of "Sat, 19 Mar 2022 10:11:39 +0100")

Fernando Ramos <greenfoo@u92.eu> writes:

> When running 'git mergetool -t vimdiff', a new configuration option
> ('mergetool.vimdiff.layout') can now be used to select how the user
> wants the different windows, tabs and buffers to be displayed.
>
> If the option is not provided, the layout will be the same one that was
> being used before this commit (ie. two rows with LOCAL, BASE and COMMIT
> in the top one and MERGED in the bottom one).
>
> The 'vimdiff' variants ('vimdiff{1,2,3}') still work but, because they
> represented nothing else than different layouts, are now internally
> implemented as a subcase of 'vimdiff' with the corresponding
> pre-configured 'layout'.
>
> Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
> ---
>  mergetools/vimdiff | 548 ++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 521 insertions(+), 27 deletions(-)
>
> diff --git a/mergetools/vimdiff b/mergetools/vimdiff
> index 96f6209a04..5bf77a5388 100644
> --- a/mergetools/vimdiff
> +++ b/mergetools/vimdiff
> @@ -1,48 +1,440 @@
> +# This script can be run in two different contexts:
> +#
> +#   - From git, when the user invokes the "vimdiff" merge tool. In this context
> +#     this script expects the following environment variables (among others) to
> +#     be defined (which is something "git" takes care of):
> +#
> +#       - $BASE
> +#       - $LOCAL
> +#       - $REMOTE
> +#       - $MERGED
> +#
> +#     In this mode, all this script does is to run the next command:
> +#
> +#         vim -f -c ... $LOCAL $BASE $REMOTE $MERGED
> +#
> +#     ...where the "..." string depends on the value of the
> +#     "mergetool.vimdiff.layout" configuration variable and is used to open vim
> +#     with a certain layout of buffers, windows and tabs.
> +#
> +#   - From the unit tests framework ("t" folder) by sourcing this script and
> +#     then manually calling "run_unit_tests", which will run a battery of unit
> +#     tests to make sure nothing breaks.
> +#     In this context this script does not expect any particular environment
> +#     variable to be set.
> +
> +
> +################################################################################
> +## Internal functions (not meant to be used outside this script)
> +################################################################################
> +
> +debug_print() { 
> +	# Send message to stderr if global variable DEBUG is set to "true"
> +
> +	if test -n "$GIT_MERGETOOL_VIMDIFF_DEBUG"
> +	then
> +		>&2 echo "$@"
> +	fi
> +}

Do we want to keep this helper, and many calls to it sprinkled in
this file, or are they leftover cruft?

Style.  "debug_print () {", i.e. SPACE on both sides of "()".

> +substring() {
> +	# Return a substring of $1 containing $3 characters starting at
> +	# zero-based offset $2.
> +	# 
> +	# Examples:
> +	#
> +	#   substring "Hello world" 0 4  --> "Hell"
> +	#   substring "Hello world" 3 4  --> "lo w"
> +	#   substring "Hello world" 3 10 --> "lo world"
> +
> +	STRING=$1
> +	START=$2
> +	LEN=$3
> +
> +	echo "$STRING" | cut -c$(( START + 1 ))-$(( START + $LEN))
> +}

The lack of space before the second closing "))" makes it look
inconsistent.  We should be able to do this no external commands
and just two variable substitutions and without relying on
bash-isms, but the above should do.

>  merge_cmd () {
> +	layout=$(git config mergetool.$merge_tool.layout)
> +
>  	case "$1" in
>  	*vimdiff)
> -		if $base_present
> +		if test -z "$layout"
>  		then
> -			"$merge_tool_path" -f -d -c '4wincmd w | wincmd J' \
> -				"$LOCAL" "$BASE" "$REMOTE" "$MERGED"
> -		else
> -			"$merge_tool_path" -f -d -c 'wincmd l' \
> -				"$LOCAL" "$MERGED" "$REMOTE"
> +			# Default layout when none is specified
> +			layout="(LOCAL,BASE,REMOTE)/MERGED"
>  		fi
>  		;;
> ...
> +	if $base_present
> +	then
> +		eval "$merge_tool_path" \
> +			-f "$FINAL_CMD" "$LOCAL" "$BASE" "$REMOTE" "$MERGED"
> +	else
> +		# If there is no BASE (example: a merge conflict in a new file
> +		# with the same name created in both braches which didn't exist
> +		# before), close all BASE windows using vim's "quit" command
> +
> +		FINAL_CMD=$(echo "$FINAL_CMD" | \
> +			sed -e 's:2b:quit:g' -e 's:3b:2b:g' -e 's:4b:3b:g')
> +
> +		eval "$merge_tool_path" \
> +			-f "$FINAL_CMD" "$LOCAL" "$REMOTE" "$MERGED"
> +	fi


I wonder if there were an easy way to "compare" the $FINAL_CMD this
new code feeds to $merge_tool_path and what was fed to it by the
original code to show that we are not regressing what the end user
sees.

The "run_unit_tests()" only compares the cmd generated for each
given layout, but the original vimdiff$N didn't express them in
terms of $layout this patch introduces, so unfortunately that is not
it.

Ideas?

  reply	other threads:[~2022-03-23 16:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-19  9:11 [PATCH v5 0/3] vimdiff: new implementation with layout support Fernando Ramos
2022-03-19  9:11 ` [PATCH v5 1/3] " Fernando Ramos
2022-03-23 16:43   ` Junio C Hamano [this message]
2022-03-24 12:21     ` Fernando
2022-03-24 16:52       ` Junio C Hamano
2022-03-24 20:50         ` Fernando
2022-03-19  9:11 ` [PATCH v5 2/3] vimdiff: add tool documentation Fernando Ramos
2022-03-19  9:11 ` [PATCH v5 3/3] vimdiff: integrate layout tests in the unit tests framework ('t' folder) Fernando Ramos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqsfr8sjpl.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=greenfoo@u92.eu \
    --cc=levraiphilippeblain@gmail.com \
    --cc=rogi@skylittlesystem.org \
    --cc=seth@eseth.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).