Ciaran <ciaranj@xxxxxxxxx> writes:
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -262,7 +262,9 @@ run_merge_tool () {
> if $base_present; then
> "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
> else
> - "$merge_tool_path" "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"
> + touch "$GIT_DIR/.no_base"
> + "$merge_tool_path" "$GIT_DIR/.no_base" "$LOCAL" "$REMOTE" "$MERGED"
> + rm "$GIT_DIR/.no_base"
The calling script "git-mergetool.sh" seems to take pains to construct
these filenames to have the same .ext, presumably so that the tool can
take advantage of it to determine the type of contents and do something
intelligent about it (e.g. syntax highlighting).
Does the use of .no_base interfere with that effort?
I suspect that you may be able to simply use "$BASE" for that, no? It
will be cleaned up when cleanup_temp_files() is run anyway (warning: I do
not use mergetool, and I am writing this only from my cursory looking of
the script, so take this with a large grain of salt).
Also, the command to use when you want to get an empty file is not "touch".
It is not likely that you would have an existing file there, but the whole
point of the updated codepath is to have an empty file, and not a file
with recent timestamp, it would be far more sensible to say
: >"$BASE"
i.e. redirect into the path, with a no-op command.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html