Closed GoogleCodeExporter closed 9 years ago
The problem is that meld's current working dir is not set to the dir from which
it was invoked, but is set instead to the dir where meld is located. So it ends
up looking for relative paths starting at the meld dir, which is certainly
wrong.
Same versions, same OS.
The attached image shows this problem more clearly. Note that meld was invoked
from the command line above, which is in the dir
C:\Users\jppm\projects\decathlon\Game to a file which is on that dir. Meld ends
up looking for the file in the meld dir, C:\Program Files (x86)\Meld\meld .
Original comment by joao.mag...@biodroid-entertainment.com
on 2 Apr 2013 at 10:35
Attachments:
I don't maintain Meld itself, only an installer for Meld. Please ask about
issues related to Meld itself on their mailing list
(https://mail.gnome.org/mailman/listinfo/meld-list) and file bugs with their
Bugzilla (https://bugzilla.gnome.org/enter_bug.cgi?product=meld).
Original comment by keeganw...@gmail.com
on 2 Apr 2013 at 3:52
Respectfully, this is not a Meld problem, as shown by the attached patch, which
fixes the issue.
It's a problem in the ahk script. That script runs with %A_ScriptDir% as its
working dir. It should run in the original working dir, and call python with
the environment set. I am not confortable with AHK, so what I did instead was
to save the initial workdir in cwd and prepend it whenever a given path is
relative.
But the ideal way to do it is to never make the call to SetWorkingDir, and
prepare the python environment instead.
Original comment by joao.mag...@biodroid-entertainment.com
on 2 Apr 2013 at 6:00
Attachments:
For those wanting a quick solution:
(Assuming your Meld installation dir is C:\Program Files (x86)\Meld)
1. Save the attached ahk script
2. Compile the ahk script with Ahk2Exe:
2.1 Source: select the ahk script
2.2 Destination: select a folder with write permissions and name your file meld.exe
2.3 Custom Icon: select C:\Program Files (x86)\Meld\meld\meld.ico
3. Copy the meld.exe into C:\Program Files (x86)\Meld\meld\meld.exe,
overwriting (you'll probably need to provide admin permissions).
Original comment by joao.mag...@biodroid-entertainment.com
on 2 Apr 2013 at 6:20
Attachments:
OK - this new version of the ahk is less hackier. It turns out that, unlike
what I wrote above, there is no need to set the Python environment. The trouble
I was having initially was (I think) related to the spaces in the Program Files
(x86) folder.
This new ahk script version completely solves this. There's no call to
SetWorkingDir, so meld now works as expected - with its workdir set to the
caller's workdir. This means meld can be called from the command line with any
sort of path (unlike my previous meld.ahk version).
Look - I am very grateful for your installer - it finally gave meld to Windows
users. But please understand that *this is a problem with the installer* (ie,
meld.ahk and consequently meld.exe) and not with Meld itself, which is fine.
Your intermediate meld.exe is making meld itself not usable when relative paths
are given (which is almost all the time in the command line).
So please remove that egregious call to SetWorkingDir, and consider using this
meld.ahk version instead.
All the best - and thanks again,
João
Original comment by joao.mag...@biodroid-entertainment.com
on 2 Apr 2013 at 11:32
Attachments:
João's script works perfectly for me when compiled down to an exe using
AHK2EXE. It's a shame that it is not in the official installer, as it can be
tedious to open two adjacent directories for comparison using the GUI.
Original comment by star99...@gmail.com
on 12 Jun 2013 at 3:37
João script worked for me as well, I can finally use git difftool with meld.
@Keegan Witt: please reconsider the status of this bug and include the changes
contributed by João. Thanks!
Original comment by joan.cha...@gmail.com
on 6 Aug 2013 at 9:01
With reading joao's post I believe it's a bug of the installer. It work's fine
with supplied meld.ahk.
I believe it's worth fixing it.
Original comment by kong...@gmail.com
on 22 Aug 2013 at 9:04
Original comment by keeganw...@gmail.com
on 6 Sep 2013 at 5:24
[deleted comment]
Original comment by keeganw...@gmail.com
on 7 Sep 2013 at 3:07
[deleted comment]
[deleted comment]
Sorry, I think I missed that you guys had commented. Thanks for your feedback.
I think this version should do what you need:
https://code.google.com/p/meld-installer/source/browse/meld.ahk?r=0b2e0e22ee8fe1
0c70030dcf7ded58c85714a082. Give it a look and let me know.
Original comment by keeganw...@gmail.com
on 8 Sep 2013 at 12:14
Original comment by keeganw...@gmail.com
on 10 Sep 2013 at 9:56
Thanks a lot for this fix!!!
Now I can use "git mergetool" with no problems.
Here is my git config:
[merge]
tool = meld
[mergetool "meld"]
prompt = false
keepBackup = false
keepTemporaries = false
path = c:/Meld/meld/meld.exe
Original comment by cch...@gmail.com
on 11 Sep 2013 at 3:13
My pleasure. Glad to hear it's working for you, and thank you for your
patience. I've modified the issue tracker here to default to me as the owner,
that should prevent something like this from being missed in the future.
Original comment by keeganw...@gmail.com
on 12 Sep 2013 at 2:48
Original comment by keeganw...@gmail.com
on 15 Sep 2013 at 3:05
Original comment by keeganw...@gmail.com
on 15 Sep 2013 at 3:06
I installed Meld with the Windows installer and I can run it manually and via
command line ok. However I can't get SourceTree it kick off the GUI interface?
It creates the BACKUP, BASE, LOCAL, REMOTE files but just won't fire up the
GUI. Any ideas what is wrong with SourceTree doing this for my git project?
My .gitconfig says:
[merge]
tool = meld
[mergetool "meld"]
prompt = false
keepBackup = false
keepTemporaries = false
path = 'c:/Program Files/Meld/meld/meld.exe'
Original comment by delettec...@gmail.com
on 15 Oct 2013 at 7:57
I'm not sure if this would correct the issue or not (I don't use Meld for
this), but have you tried using meldc.exe instead of meld.exe? This was added
in the last release.
Original comment by keeganw...@gmail.com
on 15 Oct 2013 at 11:15
Try adding meld.exe to your path. I don't know SourceTree, but if SourceTree
itself calls Meld (instead of letting git do it) then meld.exe needs to be in
your path.
Original comment by joao.mag...@biodroid-entertainment.com
on 15 Oct 2013 at 11:33
Hi there,
If you are using a Windows of non-English version, you can try change system
format to English:
Control Panel -> Region and Language -> Formats.
Working within windows is totally a nightmare.
Original comment by kong...@gmail.com
on 16 Oct 2013 at 4:01
Meldc.exe didn't work. Sourcetree should be using native git commands.
I can see the sh.exe open up in my task manager but it's doing nothing.
Original comment by delettec...@gmail.com
on 21 Oct 2013 at 6:22
Did you mean cmd.exe instead of sh.exe? I'm unsure what to recommend. Setting
my .gitconfig as you have works with SourceTree. Are you running a 64bit
version of Windows? If so, make sure you're pointing at %PROGRAMFILES(x86)%.
Original comment by keeganw...@gmail.com
on 21 Oct 2013 at 11:35
If you did mean sh.exe, I wonder if differences in path separators could cause
that. Also when I was testing, I was using mysysgit, and not Git from Cygwin
or something else. I'm trying to think what else could be different in our
setups.
Original comment by keeganw...@gmail.com
on 22 Oct 2013 at 4:09
Original issue reported on code.google.com by
tom...@gmail.com
on 22 Feb 2013 at 5:29Attachments: