From: Junio C Hamano <gitster@pobox.com>
To: Robin Rosenberg <robin.rosenberg@dewire.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v4] Allow the user to change the temporary file name for mergetool
Date: Thu, 21 Aug 2014 13:04:24 -0700 [thread overview]
Message-ID: <xmqqvbplr4mv.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1408607240-11369-1-git-send-email-robin.rosenberg@dewire.com> (Robin Rosenberg's message of "Thu, 21 Aug 2014 09:47:20 +0200")
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> 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.
> 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.
next prev parent reply other threads:[~2014-08-21 20:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-19 12:22 [PATCH] Allow the user to change the temporary file name for mergetool Robin Rosenberg
2014-08-19 12:52 ` Stefan Näwe
2014-08-19 14:55 ` [PATCH v2] " Robin Rosenberg
2014-08-19 17:02 ` Junio C Hamano
2014-08-19 17:15 ` [PATCH v3] " Robin Rosenberg
2014-08-19 18:01 ` Junio C Hamano
2014-08-19 20:36 ` Johannes Sixt
2014-08-19 22:14 ` Junio C Hamano
2014-08-20 7:24 ` Robin Rosenberg
2014-08-21 7:47 ` [PATCH v4] " Robin Rosenberg
2014-08-21 20:04 ` Junio C Hamano [this message]
2014-08-20 7:22 ` [PATCH v3] " Stefan Näwe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqvbplr4mv.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=robin.rosenberg@dewire.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.