From: David Aguilar <davvid@gmail.com>
To: Markus Heidelberg <markus.heidelberg@web.de>
Cc: gitster@pobox.com, snowcoder@gmail.com, spearce@spearce.org,
Johannes.Schindelin@gmx.de, git@vger.kernel.org,
charles@hashpling.org
Subject: Re: [PATCH] mergetool--lib: add support for araxis merge
Date: Sun, 3 May 2009 17:09:57 -0700 [thread overview]
Message-ID: <20090504000956.GD50640@gmail.com> (raw)
In-Reply-To: <200905030854.28059.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> wrote:
>
> Haven't you included the -title[1-3] command line switches because of
> the strange "'title'" format? The user on the msysgit list had commented
> it out in his patch, although he said it worked in this way. And looking
> at git-gui/lib/mergetool.tcl, it is done in the same way.
>
> Markus
I looked into it.
Windows. :(
-title1:"nice stuff" works great everywhere except for windows.
-title1:"'nice stuff'" doesn't work there either.
That's probably why it was commented out in the original patch.
On windows we'd have to escape the spaces (wild guess) so the
original patch is probably the best option since I don't feel
like making the other platforms suffer for it.
Seeing .diff_XXXX as the filename is bad too (and that is a
form of suffering as well) but it's a compromise since there
is a possibility that we could fix that elsewhere to
everyone's benefit.
As far as difftool is concerned, the code that generates
the temp filename is prep_temp_blob() in diff.c.
It's used by several callers that naturally care nothing
about filenames.
It would be nice to specialize the ext-diff code to
generate a more intuitive filename. Maybe something
like original_filename.XXXXX.ext instead of the current
.diff_XXXXX. Right now the choice of filename breaks
syntax highlighting in some viewers and also makes
the usage of --title args necessary since the default
names tell us nothing about what we're viewing.
That's definitely not the kind of thing to be thinking
about during an -rc cycle ;), though I would be interested
in maybe working on that later if others agree that
it's not a bad idea.
It wouldn't be perfect, but it would be just a
little bit nicer for anyone that's using the tools
everyday.
--
David
next prev parent reply other threads:[~2009-05-04 0:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-03 1:18 [PATCH] mergetool--lib: add support for araxis merge David Aguilar
2009-05-03 6:54 ` Markus Heidelberg
2009-05-03 18:20 ` David Aguilar
2009-05-04 0:09 ` David Aguilar [this message]
2009-05-09 20:56 ` Markus Heidelberg
2009-05-03 14:30 ` Johannes Schindelin
2009-05-03 18:18 ` David Aguilar
-- strict thread matches above, loose matches on Subject: below --
2009-05-18 3:18 David Aguilar
2009-05-23 14:29 ` Markus Heidelberg
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=20090504000956.GD50640@gmail.com \
--to=davvid@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=charles@hashpling.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=markus.heidelberg@web.de \
--cc=snowcoder@gmail.com \
--cc=spearce@spearce.org \
/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.