On September 13, 2025 3:05 AM, Johannes Sixt wrote:
>Am 12.09.25 um 22:16 schrieb rsbecker@xxxxxxxxxxxxx:
>> I am trying to integrate a custom mergetool with a shell wrapper.
>> What I get from the online help is the following description referring
>> to the command and environment variables.
>>
>> mergetool.<tool>.cmd
>> Specify the command to invoke the specified merge tool.
>> The specified command is evaluated in shell with the following
>> variables available: BASE is the name of a
>
>Take note: this talks about "variables", not "environment variables".
>
>> temporary file containing the common base of the files to be merged,
>> if available; LOCAL is the name of a temporary file containing the
>> contents of the file on the current branch; REMOTE is the name of a
>> temporary file containing the contents of the file from the branch
>> being merged; MERGED contains the name of the file to which the merge
>> tool should write the results of a successful merge.
>>
>> When I try to use this from a shell, simply with:
>> #!/bin/sh
>> env
>> exit 1
>>
>> the described environment variables: BASE, LOCAL, REMOTE, and MERGED,
>> are not present.
>
>Look at the scripts in the directory mergetools/ and note that they are only (large)
>shell code fragements without a shbang line. They are not even executable.
Let me try to infer what is happening and please correct me if my assumptions
are wrong:
Git includes an existing shell fragment with the appropriate tool name from
git-core/mergetools/tool-name instead of creating a dedicated shell in which to
run the merge tool script.
It then uses ${merge-tool-path} to execute the tool based on whether diff_cmd() or
merge_cmd() is invoked. Because BASE, LOCAL, REMOTE, and MERGED are not
exported, they are not visible to sub-shells.
This does not apply if the tool is unknown to the mergetools directory, so must be
contributed and packaged into git to work according to the documentation.
So a custom mergetool will not have access to these variables and has to hack
through what is in the working index based on file_BASE_num, etc. instead of
having direct information on what is being merged.
That about right?
