Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH] Copy mergetool "bc3" as "bc4"

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:02:45

Olivier Croquette [off-list ref] writes:
Beyond compare 4 is out since september 2014. The CLI interface
doesn't seem to have changed compared to the version 3.
Hmph, if this is identical to mergetools/bc3, why is the patch even
needed?  Do we auto-detect something and try to use bc4 which does
not exist and fail, and we must supply a copy as bc4 to prevent it?

It may feel somewhat strange to have to say "mergetool --tool=bc3"
when you know what you have is version 4 and not version 3, but in
that case, I wonder if there are reasons why calling both versions
just "bc" is a bad idea.  And assuming that version 5 and later
would keep the same interface, we will not have to worry about that
"I have version 7 why do I have to say 3?" if we can go that route.

Perhaps version 2 and before are unusable as a mergetool backend or
something?
quoted hunk
Signed-off-by: Olivier Croquette <redacted>
---
 mergetools/bc4 |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)
 create mode 100644 mergetools/bc4
diff --git a/mergetools/bc4 b/mergetools/bc4
new file mode 100644
index 0000000..b6319d2
--- /dev/null
+++ b/mergetools/bc4
@@ -0,0 +1,25 @@
+diff_cmd () {
+	"$merge_tool_path" "$LOCAL" "$REMOTE"
+}
+
+merge_cmd () {
+	touch "$BACKUP"
+	if $base_present
+	then
+		"$merge_tool_path" "$LOCAL" "$REMOTE" "$BASE" \
+			-mergeoutput="$MERGED"
+	else
+		"$merge_tool_path" "$LOCAL" "$REMOTE" \
+			-mergeoutput="$MERGED"
+	fi
+	check_unchanged
+}
+
+translate_merge_tool_path() {
+	if type bcomp >/dev/null 2>/dev/null
+	then
+		echo bcomp
+	else
+		echo bcompare
+	fi
+}
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help