git gui: add directly calling merge tool from gitconfig #1773
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Welcome to GitGitGadgetHi @ToBoMi, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests. Please make sure that either:
You can CC potential reviewers by adding a footer to the PR description with the following syntax: NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description, Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:
It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code. Contributing the patchesBefore you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form Both the person who commented An alternative is the channel Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment If you want to see what email(s) would be sent for a After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail). If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the curl -g --user "<EMailAddress>:<Password>" \
--url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txtTo iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description): To send a new iteration, just add another PR comment with the contents: Need help?New contributors who want advice are encouraged to join [email protected], where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join. You may also be able to find help in real time in the developer IRC channel, |
|
There are issues in commit 7119d6d: |
ToBoMi
force-pushed
the
add_merge_tool_from_config_file
branch
2 times, most recently
from
995601d
to
ad83e81
Compare
ToBoMi
changed the title
|
I am new to this and would like to be |
|
/allow |
|
User ToBoMi is now allowed to use GitGitGadget. WARNING: ToBoMi has no public email address set on GitHub; |
|
Error: Could not determine full name of ToBoMi |
|
/preview |
|
Preview email sent as [email protected] |
|
/preview |
|
Preview email sent as [email protected] |
ToBoMi
force-pushed
the
add_merge_tool_from_config_file
branch
from
ad83e81
to
59e8f45
Compare
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
|
On the Git mailing list, Johannes Sixt wrote (reply to this): Am 19.08.24 um 13:29 schrieb ToBoMi via GitGitGadget:
> From: deboeto <[email protected]>
>
> * git Gui can open a merge tool when conflicts are
> detected. The merge tools that are allowed to
> call have to be hard coded into git Gui
> althgough there are configuration options for
> merge tools git in the git config. Git calls
> the configured merge tools directly from the
> config while git Gui doesn't.
> * git Gui can now call the tool configured in the
> gitconfig directly.
> * Can be enabled through setting
> gui.mergeToolFromConfig
Can we do better than having a new configuration variable? Let's say you
have configured merge.tool=vscode. This tool is not supported, but you
have configured mergetool.vscode.cmd suitably. Can we not use the latter
configuration variable unconditionally?
Likewise, say, you have configured merge.tool=bc3. This one *is*
supported. What could go wrong if mergetool.bc3.cmd is used instead of
the built-in command line? The behavior would change for users that
configured mergetool.$tool.cmd for a supported tool. But would it change
for the worse?
BTW, the code builds different command lines depending on whether a base
file is available or not. How does mergetool.$tool.cmd handle the cases?
> * Disabled by default, since option is most likely
> never set
> * bc3 and vscode tested
>
> Signed-off-by: deboeto <[email protected]>
Some remarks on the commit message:
- The Signed-off-by line has legal consequences. Therefore, we require
that authors use their genuine name, not an alias. Also, the From line
must match the Signed-off-by line.
- Please have a look at the commit messages in the code base. The
formatting presented here is very unusual. Please write in full
sentences including punctuation, and use paragraphs where needed.
- Please state the problem that is being solved (in present tense). This
should motivate the change, i.e., provide a convincing argument why the
change is needed. Then state what the solution is in imperative mood,
that is, an instruction to the code to change in such and such way. Use
examples to clarify how the new feature can be used.
> ---
> git gui: add directly calling merge tool from gitconfig
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1773%2FToBoMi%2Fadd_merge_tool_from_config_file-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1773/ToBoMi/add_merge_tool_from_config_file-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/1773
>
> Documentation/config/gui.txt | 4 ++++
> git-gui/lib/mergetool.tcl | 11 +++++++++--
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/config/gui.txt b/Documentation/config/gui.txt
> index 171be774d24..e63d0b46e7c 100644
> --- a/Documentation/config/gui.txt
> +++ b/Documentation/config/gui.txt
> @@ -55,3 +55,7 @@ gui.blamehistoryctx::
> linkgit:gitk[1] for the selected commit, when the `Show History
> Context` menu item is invoked from 'git gui blame'. If this
> variable is set to zero, the whole history is shown.
> +
> +gui.mergeToolFromConfig::
> + If true, allow to call the merge tool configured in gitconfig
> + in git gui directly.
> \ No newline at end of file
Unfortunately, Documentation/config/gui.txt is not part of the Git GUI
repository. Any changes to the documentation must be submitted as
separate patch.
Please be careful not to introduce an incomplete last lines. Take note
of "No newline at end of file". It should not be there.
> diff --git a/git-gui/lib/mergetool.tcl b/git-gui/lib/mergetool.tcl
> index e688b016ef6..fbd0889612a 100644
> --- a/git-gui/lib/mergetool.tcl
> +++ b/git-gui/lib/mergetool.tcl
> @@ -272,8 +272,15 @@ proc merge_resolve_tool2 {} {
> }
> }
> default {
> - error_popup [mc "Unsupported merge tool '%s'" $tool]
> - return
> + if {[is_config_true gui.mergetoolfromconfig]} {
> + set path [get_config mergetool.$tool.path]
At this point, the value assigned to $path here is already available in
$merge_tool_path.
> + set cmdline_config [get_config mergetool.$tool.cmd]
> + set cmdline_substituted [subst -nobackslashes -nocommands $cmdline_config]
> + set cmdline [lreplace $cmdline_substituted 0 0 $path]
I haven't yet taken the time to study what these lines do (I am far from
fluent in Tcl) and have no opinion, yet.
> + } else {
> + error_popup [mc "Unsupported merge tool '%s'" $tool]
> + return
> + }
> }
> }
>
>
> base-commit: b9849e4f7631d80f146d159bf7b60263b3205632
-- Hannes
|
|
User |
ToBoMi
force-pushed
the
add_merge_tool_from_config_file
branch
from
59e8f45
to
e77d6de
Compare
|
/preview |
|
Preview email sent as [email protected] |
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): "ToBoMi via GitGitGadget" <[email protected]> writes:
> From: deboeto <[email protected]>
Use the same ident (human readable name plus e-mail address) you
have on your Signed-off-by: line below for this "From: " in-body
header.
> git gui can open a merge tool when conflicts are
> detected (Right click in the diff of the file with
> conflicts).
> The merge tools that are allowed to
> use are hard coded into git gui.
>
> If one wants to add a new merge tool it has to be
> added to git gui through a source code change.
> This is not convenient in comparison to how it
> works in git (without gui).
>
> git itself has configuration options for a merge tools
> path and command in the git config.
> New merge tools can be set up there without a
> source code change.
Even if you configure an unknown tool, it would not get any benefit
from what git-{diff,merge}tool--lib.sh gives the known diff/merge
backends, would it? Instead of a more thorough support for known
tools done in setup_tool(), an unknown tool would be handled by
setup_user_tool() in git-mergetool-lib.sh which gives somewhat
degraded support.
So "can be set up without" may be true, but giving an impression
that a tool that is set up like so would work just like a known tool
is misleading.
By the way, we do ask contributors to avoid overly long lines,
50-col limt is a bit overly short and makes the resulting text
harder to read than necessary.
> Those options are used only by pure git in
> contrast to git gui. git calls the configured
> merge tools directly from the config while git
> Gui doesn't.
>
> With this change git gui can call merge tools
> configured in the gitconfig directly without a
> change in git gui source code.
> It needs a configured merge.tool and a configured
> mergetool.cmd config entry.
OK.
> gitconfig example:
> [merge]
> tool = vscode
> [mergetool "vscode"]
> path = the/path/to/Code.exe
> cmd = \"Code.exe\" --wait --merge \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$MERGED\"
>
> Without the mergetool.cmd configuration and an
> unsupported merge.tool entry, git gui behaves
> mainly as before this change and informs the user
> about an unsupported merge tool, but now also
> shows a hint to add a config entry for the tool
> in gitconfig.
>
> If a wrong mergetool.cmd is configured by accident
> it is beeing handled by git gui already. In this
"is beeing" -> "is being", but "it gets handled by Git GUI already"
should be sufficient.
> case git gui informs the user that the merge tool
> couldn't be opened. This behavior is preserved by
> this change and should not change.
>
> Beyond compare 3 and Visual Studio code were
> tested as manually configured merge tools.
Quote proper nouns for readability? E.g.
"Beyond Compare 3" and "Visual Studio Code" were ...
Thanks. |
|
On the Git mailing list, Johannes Sixt wrote (reply to this): Am 28.08.24 um 10:31 schrieb ToBoMi via GitGitGadget:
> From: deboeto <[email protected]>
>
> git gui can open a merge tool when conflicts are
> detected (Right click in the diff of the file with
> conflicts).
> The merge tools that are allowed to
> use are hard coded into git gui.
>
> If one wants to add a new merge tool it has to be
> added to git gui through a source code change.
> This is not convenient in comparison to how it
> works in git (without gui).
>
> git itself has configuration options for a merge tools
> path and command in the git config.
> New merge tools can be set up there without a
> source code change.
>
> Those options are used only by pure git in
> contrast to git gui. git calls the configured
> merge tools directly from the config while git
> Gui doesn't.
>
> With this change git gui can call merge tools
> configured in the gitconfig directly without a
> change in git gui source code.
> It needs a configured merge.tool and a configured
> mergetool.cmd config entry.
OK.
> gitconfig example:
> [merge]
> tool = vscode
> [mergetool "vscode"]
> path = the/path/to/Code.exe
> cmd = \"Code.exe\" --wait --merge \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$MERGED\"
I found it annoying that I had to configure .path in addition to .cmd.
Typically, you would put the correct path into the .cmd configuration.
In fact, `git mergetool` works without .path and fails when .cmd does
not contain the correct path.
> Without the mergetool.cmd configuration and an
> unsupported merge.tool entry, git gui behaves
> mainly as before this change and informs the user
> about an unsupported merge tool, but now also
> shows a hint to add a config entry for the tool
> in gitconfig.
Good.
While testing I configured meld incorrectly once and got no feedback
whatsoever, but I would not attribute this to this patch.
There is no such thing called "gitconfig". Just strike "in gitconfig".
> If a wrong mergetool.cmd is configured by accident
> it is beeing handled by git gui already. In this
> case git gui informs the user that the merge tool
> couldn't be opened. This behavior is preserved by
> this change and should not change.
Good.
>
> Beyond compare 3 and Visual Studio code were
> tested as manually configured merge tools.
>
> Signed-off-by: Tobias Boesch <[email protected]>
You updated this line, but not the From: line. Would you mind
configuring your user.name and then `git commit --amend --reset-author`?
> git-gui/lib/mergetool.tcl | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/git-gui/lib/mergetool.tcl b/git-gui/lib/mergetool.tcl
> index e688b016ef6..4c4e8f47bb0 100644
> --- a/git-gui/lib/mergetool.tcl
> +++ b/git-gui/lib/mergetool.tcl
> @@ -272,8 +272,14 @@ proc merge_resolve_tool2 {} {
> }
> }
> default {
> - error_popup [mc "Unsupported merge tool '%s'" $tool]
> - return
> + set tool_cmd [get_config mergetool.$tool.cmd]
> + if {$tool_cmd ne {}} {
> + set tool_cmd_file_vars_resolved [subst -nobackslashes -nocommands $tool_cmd]
I just learnt that a string value containing double-quotes is broken
into a list in the expected way (keeps quoted parts together as a single
element). However, this form of substitution replaces variable values
with arbitrary text without taking into account that the original string
is actually a list. Should we not break the string into a list first,
and apply the substitution on the list elements?
If there is a straight-forward way to do this (say, an obvious two-liner
at most), we should do it. Otherwise, I can live with this solution for
now because it requires file names with double-quotes to break the
expected list nature.
There is another thing, though, that I would not want to take as
lightly: The -nocommands modifier of `subst` does not live up to its
promises, and it is even the documented behavior: command substitutions
in array indexes are still executed. Consider this configuration:
[merge]
tool = evil
[mergetool "evil"]
cmd = meld \"$REMOTE([exit])\"
Guess what happens when I run the merge tool? It exits Git GUI!
I suggest to reject any configuration that contains an opening bracket
'[' or anything else that introduces a command execution.
> + set cmdline [lreplace $tool_cmd_file_vars_resolved 0 0 $merge_tool_path]
> + } else {
> + error_popup [mc "Unsupported merge tool '%s'. Is the tool command and path configured properly in gitconfig?" $tool]
Can we not have a more helpful text? How about
error_popup [mc "Unsupported merge tool '%s'.
See the git-config manual page how to configure mergetool.%s.cmd
suitably." $tool $tool]
> + return
> + }
> }
> }
>
-- Hannes
|
|
User |
ToBoMi
force-pushed
the
add_merge_tool_from_config_file
branch
2 times, most recently
from
6636903
to
c8c0107
Compare
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
|
On the Git mailing list, Johannes Sixt wrote (reply to this): Am 06.09.24 um 08:32 schrieb [email protected]:
>> Von: Johannes Sixt <[email protected]>
>> While testing I configured meld incorrectly once and got no feedback
>> whatsoever, but I would not attribute this to this patch.
>>
>
> That's odd. I tested this again by setting merge.tool to "meld" and
> configured mergetool.cmd to "some wrong path". When starting the
> mergetool I got a popup saying that meld was not found in path.
But if the configuration is
cmd = "meld far too many arguments provided"
and 'meld' *is* in the path, then there is no feedback because meld can
be started successfully, but reports an error only on stdout or stderr,
which is ignored by Git GUI. And the exit code seems to be ignored, too.
But this can be treated in a follow-up patch if necessary.
-- Hannes
|
|
On the Git mailing list, Johannes Sixt wrote (reply to this): Am 06.09.24 um 09:27 schrieb ToBoMi via GitGitGadget:
> From: Tobias Boesch <[email protected]>
>
> git gui can open a merge tool when conflicts are detected (Right click
> in the diff of the file with conflicts).
> The merge tools that are allowed to use are hard coded into git gui.
>
> If one wants to add a new merge tool it has to be added to git gui
> through a source code change.
> This is not convenient in comparison to how it works in git (without gui).
>
> git itself has configuration options for a merge tools path and command
> in the git config.
> New merge tools can be set up there without a source code change.
>
> Those options are used only by pure git in contrast to git gui. git calls
> the configured merge tools directly from the config while git Gui doesn't.
>
> With this change git gui can call merge tools configured in the gitconfig
> directly without a change in git gui source code.
> It needs a configured merge.tool and a configured mergetool.cmd config
> entry.
The configuration is "mergetool.$tool.cmd"!
Personally, I would avoid the words "gitconfig" and "config" (here and
in the rest of the commit message), neither of which are English.
"Configuration" would be OK, IMO.
>
> gitconfig example:
> [merge]
> tool = vscode
> [mergetool "vscode"]
> path = the/path/to/Code.exe
> cmd = \"Code.exe\" --wait --merge \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$MERGED\"
>
> Without the mergetool.cmd configuration and an unsupported merge.tool
> entry, git gui behaves mainly as before this change and informs the user
> about an unsupported merge tool. In addtition it also shows a hint to add
> a config entry to use the tool as an unsupported tool with degraded
> support.
>
> If a wrong mergetool.cmd is configured by accident, it gets handled
> by git gui already. In this case git gui informs the user that the merge
> tool couldn't be opened. This behavior is preserved by this change and
> should not change.
>
> "Beyond Compare 3" and "Visual Studio Code" were tested as manually
> configured merge tools.
>
> Signed-off-by: Tobias Boesch <[email protected]>
> ---
> git-gui/lib/mergetool.tcl | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/git-gui/lib/mergetool.tcl b/git-gui/lib/mergetool.tcl
> index e688b016ef6..ccbc1a46554 100644
> --- a/git-gui/lib/mergetool.tcl
> +++ b/git-gui/lib/mergetool.tcl
> @@ -272,8 +272,24 @@ proc merge_resolve_tool2 {} {
> }
> }
> default {
> - error_popup [mc "Unsupported merge tool '%s'" $tool]
> - return
> + set tool_cmd [get_config mergetool.$tool.cmd]
> + if {$tool_cmd ne {}} {
> + if {([string first {[} $tool_cmd] != -1) || ([string first {]} $tool_cmd] != -1)} {
> + error_popup [mc "Unable to process square brackets in mergetool.cmd configuration option.\
> + Please remove the square brackets."]
> + return
Condition and error text are OK. But see below.
> + } else {
> + foreach command_part $tool_cmd {
> + lappend cmdline [subst -nobackslashes -nocommands $command_part]
> + }
Good.
I have seen a few examples in the Tcl manual with lappend in the loop
body, and it seems to be customary to set the list variable to an empty
value before the loop, i.e.
set cmdline {}
> + }
> + } else {
> + error_popup [mc "Unsupported merge tool '%s'.\n
> + Currently unsupported tools can be added and used as unsupported tools with degraded support\
> + by adding the command of the tool to the \"mergetool.cmd\" option in the config.
> + See the configuration documentation for more details." $tool]
This error message needs a bit more work (some of this also applies to
the message above):
- A tool is only unsupported as long as there is no usable
configuration. Once mergetool.$tool.cmd is set to something we can
handle, calling the tool "unsupported" isn't appropriate, I would think.
How about
Unsupported merge tool '%s'.
To use this tool, configure "mergetool.%s.cmd" as shown in the
git-config manual page.
- The configuration variable that we use is not mergetool.cmd, but
mergetool.$tool.cmd.
- Continuation lines must not be indented. Indented text appears
indented in the error message.
- Watch out whether an explicit \n is given, whether the line-break is
escaped or not; all of this has meaning.
- Looking at other multi-line error messages in git-gui.sh, the
convention is
mc["First paragraph goes here.
Second paragraph. All of it is on one line in the source code.
Third paragraph. No \n appears anywhere."]
> + return
> + }
> }
> }
As a matter of personal taste, I prefer to structure code with error
exits like so (but it is totally acceptable if you disagree):
if {check for error 1} {
error msg1
return
}
if {check for error 2} {
error msg2
return
}
regular case
goes here
without indentation
Note that there are no else-branches. This reduces the indentation levels.
-- Hannes
|
ToBoMi
force-pushed
the
add_merge_tool_from_config_file
branch
from
c8c0107
to
b5db899
Compare
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
git gui can open a merge tool when conflicts are detected (Right click in the diff of the file with conflicts). The merge tools that are allowed to use are hard coded into git gui. If one wants to add a new merge tool it has to be added to git gui through a source code change. This is not convenient in comparison to how it works in git (without gui). git itself has configuration options for a merge tools path and command in the git configuration. New merge tools can be set up there without a source code change. Those options are used only by pure git in contrast to git gui. git calls the configured merge tools directly from the configuration while git Gui doesn't. With this change git gui can call merge tools configured in the configuration directly without a change in git gui source code. It needs a configured "merge.tool" and a configured "mergetool.<mergetool name>.cmd" configuration entry as shown in the git-config manual page. Configuration example: [merge] tool = vscode [mergetool "vscode"] path = the/path/to/Code.exe cmd = \"Code.exe\" --wait --merge \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$MERGED\" Without the "mergetool.cmd" configuration and an unsupported "merge.tool" entry, git gui behaves mainly as before this change and informs the user about an unsupported merge tool. In addtition it also shows a hint to add a configuration entry to use the tool as an unsupported tool with degraded support. If a wrong "mergetool.cmd" is configured by accident, it gets handled by git gui already. In this case git gui informs the user that the merge tool couldn't be opened. This behavior is preserved by this change and should not change. "Beyond Compare 3" and "Visual Studio Code" were tested as manually configured merge tools. Signed-off-by: Tobias Boesch <[email protected]>
ToBoMi
force-pushed
the
add_merge_tool_from_config_file
branch
from
b5db899
to
c37db60
Compare
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
|
On the Git mailing list, Johannes Sixt wrote (reply to this): Am 12.09.24 um 12:17 schrieb ToBoMi via GitGitGadget:
> Configuration example:
> [merge]
> tool = vscode
> [mergetool "vscode"]
> path = the/path/to/Code.exe
> cmd = \"Code.exe\" --wait --merge \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$MERGED\"
This example is not up-to-date anymore, is it?
Also, below are two cases where "mergetool.cmd" is mentioned
incorrectly.
> Without the "mergetool.cmd" configuration and an unsupported "merge.tool"
> entry, git gui behaves mainly as before this change and informs the user
> about an unsupported merge tool. In addtition it also shows a hint to add
> a configuration entry to use the tool as an unsupported tool with degraded
> support.
>
> If a wrong "mergetool.cmd" is configured by accident, it gets handled
> by git gui already. In this case git gui informs the user that the merge
> tool couldn't be opened. This behavior is preserved by this change and
> should not change.
> --- a/git-gui/lib/mergetool.tcl
> +++ b/git-gui/lib/mergetool.tcl
> @@ -272,8 +272,26 @@ proc merge_resolve_tool2 {} {
> }
> }
> default {
> - error_popup [mc "Unsupported merge tool '%s'" $tool]
> - return
> + set tool_cmd [get_config mergetool.$tool.cmd]
> + if {$tool_cmd ne {}} {
> + if {([string first {[} $tool_cmd] != -1) || ([string first {]} $tool_cmd] != -1)} {
> + error_popup [mc "Unable to process square brackets in mergetool.$tool.cmd configuration option.
This $tool in the format string breaks [mc]. It must be %s and an
argument. I'll fix this up while queuing.
> +
> +Please remove the square brackets."]
> + return
> + } else {
> + set cmdline {}
> + foreach command_part $tool_cmd {
> + lappend cmdline [subst -nobackslashes -nocommands $command_part]
> + }
> + }
> + } else {
> + error_popup [mc "Unsupported merge tool '%s'.
> +
> +To use this tool, configure \"mergetool.%s.cmd\" as shown in the git-config\> +manual page." $tool $tool]
I am surprised that the backslash does not paste the two lines together
without a space. "git-config" and "manual" do appear as separate words
in the error message. Nevertheless, since I do not know how this pans
out in the translation files, I will remove the line continuation and
write all on one line.
> + return
> + }
> }
> }
Thank you for your contribution! Below is the range-diff between this
submission and the queued version.
-- Hannes
1: 03e92d6 ! 1: 8ff65c7 git gui: add directly calling merge tool from configuration
@@ Commit message
[merge]
tool = vscode
[mergetool "vscode"]
- path = the/path/to/Code.exe
- cmd = \"Code.exe\" --wait --merge \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$MERGED\"
+ cmd = \"the/path/to/Code.exe\" --wait --merge \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$MERGED\"
- Without the "mergetool.cmd" configuration and an unsupported "merge.tool"
- entry, git gui behaves mainly as before this change and informs the user
- about an unsupported merge tool. In addtition it also shows a hint to add
- a configuration entry to use the tool as an unsupported tool with degraded
- support.
+ Without the "mergetool.<mergetool name>.cmd" entry and an unsupported
+ "merge.tool" entry, git gui behaves mainly as before this change and
+ informs the user about an unsupported merge tool. In addtition, it also
+ shows a hint to add a configuration entry to use the tool as an
+ unsupported tool with degraded support.
- If a wrong "mergetool.cmd" is configured by accident, it gets handled
- by git gui already. In this case git gui informs the user that the merge
- tool couldn't be opened. This behavior is preserved by this change and
- should not change.
+ If a wrong "mergetool.<mergetool name>.cmd" is configured by accident,
+ it gets handled by git gui already. In this case git gui informs the
+ user that the merge tool couldn't be opened. This behavior is preserved
+ by this change and should not change.
"Beyond Compare 3" and "Visual Studio Code" were tested as manually
configured merge tools.
Signed-off-by: Tobias Boesch <[email protected]>
+ Signed-off-by: Johannes Sixt <[email protected]>
## lib/mergetool.tcl ##
@@ lib/mergetool.tcl: proc merge_resolve_tool2 {} {
@@ lib/mergetool.tcl: proc merge_resolve_tool2 {} {
+ set tool_cmd [get_config mergetool.$tool.cmd]
+ if {$tool_cmd ne {}} {
+ if {([string first {[} $tool_cmd] != -1) || ([string first {]} $tool_cmd] != -1)} {
-+ error_popup [mc "Unable to process square brackets in mergetool.$tool.cmd configuration option.
++ error_popup [mc "Unable to process square brackets in \"mergetool.%s.cmd\" configuration option.
+
-+Please remove the square brackets."]
++Please remove the square brackets." $tool]
+ return
+ } else {
+ set cmdline {}
@@ lib/mergetool.tcl: proc merge_resolve_tool2 {} {
+ } else {
+ error_popup [mc "Unsupported merge tool '%s'.
+
-+To use this tool, configure \"mergetool.%s.cmd\" as shown in the git-config\
-+manual page." $tool $tool]
++To use this tool, configure \"mergetool.%s.cmd\" as shown in the git-config manual page." $tool $tool]
+ return
+ }
}
|
|
On the Git mailing list, Johannes Sixt wrote (reply to this): Am 07.11.24 um 15:16 schrieb [email protected]:
> The documentation (https://git-scm.com/docs/
> MyFirstContribution#after-approval) says that my "change will be
> placed into seen fairly early on by the maintainer while it is still
> in the review process".
This document is only about contributions to git.git. Git-GUI has its
own repository and workflow.
> Since I cannot find it in seen or anywhere else, I wonder if there
> is something wrong, if it just takes a little longer than I expected
> it to be merged or if this change is merged somewhere else.
There is nothing wrong, except that it's on me now to submit a pull
request to the Git maintainer. This should happen in the next days.
-- Hannes
|
|
This branch is now known as |
|
This patch series was integrated into seen via git@4925501. |
|
This patch series was integrated into master via git@4925501. |
|
This patch series was integrated into next via git@4925501. |
|
Closed via 4925501. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
cc: Johannes Sixt [email protected]
Changes since v1:
Changes since v2:
Changes since v3:
Changes since v4:
cc: Johannes Sixt [email protected]