Re: Feature Request: user defined suffix for temp files created by git-mergetool

Hi David,

thank you very much for your reply.
Today I realized, that my attachment has been cut off, so I sent it in the morning [1].

I believe, that most of answer can be find in my previous email from this morning.
Only change, that should be done by this request is add possibility to edit hard-coded suffix of temporary files. 
I don't think, that change hard-coded suffix to switch between two hard-coded suffix of temporary files is suitable solution, but as well it's not bad solution.

Please look at the patch [1] and tell me, what do you think about this change.

[1] http://marc.info/?l=git&m=147565363609649&w=2

Regards
Josef

| Sent: Wednesday, October 5, 2016 11:47:06 AM
| 
| 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 [off-list ref] 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
|