Re: [PATCH v4] Allow the user to change the temporary file name for mergetool

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 21, 2014, 20:04 UTC
Message-ID: <xmqqvbplr4mv.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1408607240-11369-1-git-send-email-robin.rosenberg@dewire.com>

Robin Rosenberg <robin.rosenberg@dewire.com> writes:

Show 14 quoted lines

> Using the original filename suffix for the temporary input files to
> the merge tool confuses IDEs like Eclipse. This patch introduces
> a configurtion option, mergetool.tmpsuffix, which get appended to
> the temporary file name. That way the user can choose to use a
> suffix like ".tmp", which does not cause confusion.
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
> ---
>  Documentation/config.txt        |  5 +++++
>  Documentation/git-mergetool.txt |  7 +++++++
>  git-mergetool.sh                | 10 ++++++----
>  3 files changed, 18 insertions(+), 4 deletions(-)
>
> Fixed a spelling error.

Show 16 quoted lines

> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index c55c22a..0e15800 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1778,6 +1778,11 @@ notes.displayRef::
>  	several times.  A warning will be issued for refs that do not
>  	exist, but a glob that does not match any refs is silently
>  	ignored.
> +
> +mergetool.tmpsuffix::
> +	A string to append the names of the temporary files mergetool
> +	creates in the worktree as input to a custom merge tool. The
> +	primary use is to avoid confusion in IDEs during merge.
>  +
>  This setting can be overridden with the `GIT_NOTES_DISPLAY_REF`
>  environment variable, which must be a colon separated list of refs or

Please read the surrounding text again and answer this question:

    What is "This setting" the continued paragraph of your paragraph
    that describes mergetool.tmpsuffix variable talks about?

Stated in another way, "match any refs is silently ignored." is the end of the first paragraph for notes.displayRef. "This setting can be overridden" is the beginning of the second paragraph for the same variable.

> +`git mergetool` may also create other temporary files for the
> +different versions involved in the merge. By default these files have
> +the same filename suffix as the file being merged. This may confuse
> +other tools in use during a long merge operation. The user can set

I would suggest these changes:

 - replace "being merged" with "being merged, so that editors and
   IDEs can use the suffix for syntax highlighting".

 - replace "this may confuse other tools" with "this may confuse
   some tools".  The same tool that takes advantage of the suffix to
   syntax-highlight may also be confused in a way that you deem
   undesirable.

 - clarify what kind of confusion this warning is talking about, and
   offer an example to avoid such confusion, and drop "in use during
   a long merge operation", as that phrase alone, without knowing
   in what way the tools are confused, is not useful to the readers.

For the last item, I unfortunately cannot offer a solid replacement phrasing, as it was not quite clear from your explanation during the discussion, at least to me. Is it that Eclipse notices that a new ".java" file in the working tree appeared and offers to add it or something? If that is the case, then perhaps I would suggest something like this:

    This reuse of the same file suffix may however confuse some
    tools.  For example, Eclipse may notice, while resolving
    conflicts on hello.java, that new files hello.LOCAL.java and
    hello.REMOTE.java appear in your working tree and helpfully
    offer to add it to your index and then upon conclusion of the
    merge it would complain because these files are now gone.  To
    avoid causing such confusion, you can use this variable to a
    suffix that your IDE does not treat specially, e.g. ".tmp" (this
    may obviously lose syntax highlighting, though).

But I am not sure what confusion you are trying to work around, so the single sentence that begins with "For example," above would need to be completely rewritten, I guess.

Thanks.