From: David Aguilar <davvid@gmail.com>
To: Josef Ridky <jridky@redhat.com>
Cc: Anatoly Borodin <anatoly.borodin@gmail.com>, git@vger.kernel.org
Subject: Re: Feature Request: user defined suffix for temp files created by git-mergetool
Date: Wed, 5 Oct 2016 02:47:06 -0700 [thread overview]
Message-ID: <20161005094706.GA18574@gmail.com> (raw)
In-Reply-To: <597741871.671633.1475558327029.JavaMail.zimbra@redhat.com>
On Tue, Oct 04, 2016 at 01:18:47AM -0400, Josef Ridky wrote:
> Hi Anatoly,
>
>
> | Sent: Monday, October 3, 2016 5:18:44 PM
> |
> | Hi Josef,
> |
> |
> | On Mon, Oct 3, 2016 at 8:36 AM, Josef Ridky <jridky@redhat.com> wrote:
> | > In several projects, we are using git mergetool for comparing files from
> | > different folders.
> | > Unfortunately, when we have opened three files for comparing using meld
> | > tool (e.q. Old_version -- Result -- New_version),
> | > we can see only name of temporary files created by mergetool in the labels
> | > (e.g. foo_REMOTE -- foo_BASE -- foo_LOCAL)
> | > and users (and sometime even we) are confused, which of the files should
> | > they edit and save.
> |
> | `git mergetool` just creates temporary files (with some temporary
> | names) and calls `meld` (or `vimdiff`, etc) with the file names as
> | parameters. So why wouldn't you call `meld` with the file names you
> | want?
>
>
> Because files, that we want, are temporary files created by
> git mergetool and we are not able to change their name.
[I didn't see your original patch, but we actually prefer inline
patches in the email, as sent via `git send-email`.
Documentation/SubmittingPatches has more details.
Please also make sure to add a test to t/t7610-mergetool.sh
exercising any new features.]
Are you proposing support for config variables to control how
the temporary files are named?
e.g. something like "mergetool.strings.{local,remote,base}" for
overriding the hard-coded {LOCAL,REMOTE,BASE} strings?
I don't want to over-engineer it, but do you want to support
executing a command to get the name, or is having a replacement
sufficient?
Now I'm curious... if replacing the strings is sufficient, what
do you plan to call them? I can imagine maybe something like
OURS, and THEIRS might be helpful since it matches the
nomenclature already used by Git, e.g. "git merge -s ours".
Since these are temporary files, changing these names might not
be entirely out of the question. This might be a case where
using the same words as a related Git feature might help reduce
the mental burden of using mergetool. OURS and THEIRS are
probably the only names that fit that category, IMO.
BASE is already good enough (merge-base).
The downside of making it configurable is that it can confuse
users who use mergetool at someone else's desk where they've
named these strings to "catty", "wombat", and "jimbo". This
doesn't seem like the kind of place where we want to allow users
to be creative, but we do care about having a good default.
OURS and THEIRS are intuitive names, so switching existing users
to those would not have much downside IMO, and it's a little
less "I just merged a REMOTE branch" centric, which is good.
Do you think these names should be changed?
If so, did you have those names in mind, or something else
entirely?
cheers,
--
David
next prev parent reply other threads:[~2016-10-05 9:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <88486231.114620.1475474318974.JavaMail.zimbra@redhat.com>
2016-10-03 6:36 ` Feature Request: user defined suffix for temp files created by git-mergetool Josef Ridky
2016-10-03 15:18 ` Anatoly Borodin
2016-10-04 5:18 ` Josef Ridky
2016-10-05 9:47 ` David Aguilar [this message]
2016-10-05 10:19 ` Josef Ridky
2016-10-05 7:47 ` Josef Ridky
2016-10-05 16:05 ` Junio C Hamano
2016-10-06 6:47 ` Josef Ridky
2016-10-05 21:04 ` Johannes Sixt
2016-10-06 7:21 ` Josef Ridky
2016-10-06 12:43 ` [PATCH 1/2] " Josef Ridky
2016-10-06 13:09 ` [PATCH 2/2] " Josef Ridky
2016-10-06 17:06 ` Junio C Hamano
2016-10-12 8:24 ` [PATCH v2 " Josef Ridky
2016-10-12 17:59 ` Junio C Hamano
2016-10-13 4:55 ` David Aguilar
2016-10-13 5:13 ` [PATCH 1/2] " David Aguilar
2016-10-06 16:58 ` Junio C Hamano
2016-10-06 15:54 ` Junio C Hamano
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161005094706.GA18574@gmail.com \
--to=davvid@gmail.com \
--cc=anatoly.borodin@gmail.com \
--cc=git@vger.kernel.org \
--cc=jridky@redhat.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).