git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

  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).