Thread (7 messages) flat view 7 messages, 4 authors, 2016-06-15

Re: [PATCH] git-mergetool--lib.sh: fix mergetool.<tool>.* configurations ignored for known tools

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:48:56

David Aguilar [off-list ref] writes:
Hi, sorry for the delay in responding to this email.
Thanks for a review.
I don't think we ever signed up to support this configuration.
mergetool.<tool>.path has always (from my naive reading of the
documentation) been the absolute path to <tool>.

I don't think it should have a dual-role where it can be either
the tool's parent directory or the path to the tool itself.
I would prefer to keep it as simple as possible, if we can.
I concur; it is not just about simplicity, but setting the value to the
parent directory of the tool feels downright confusing.
quoted
+		# mergetool.<tool>.path is the same as mergetool.<tool>.cmd
...
+	fi
This section is getting pretty nested.
Should we break the handling for configs-that-override-builtins
into a separate function?
Sounds like a sane thing to do.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help