Does anyone use Meld as Git's merge tool? If I add an extra flag to have it wait for the exit code, wouldn't that require changes to their execution script (https://github.com/git/git/blob/master/mergetools/meld)? That is, they couldn't just specify the executable path anymore, they'd also need to add the flag we're talking about adding, whereas if it was separate executables they could just choose one or the other. Much as I hate the duplication, maybe it's better to have two executables after all. Or am I misreading this?
-Keegan On Sun, Sep 29, 2013 at 11:08 PM, Keegan Witt <[email protected]> wrote: > Not that I've been able to find, no. I've coded up that change, I'm > checking with the person who originally requested this change to make sure > there's no downside with his use case. If nobody objects, I'll make > another release with this change. > > -Keegan > > > On Sun, Sep 29, 2013 at 2:49 PM, Angel Ezquerra > <[email protected]>wrote: > >> The flag idea may be ok. Could it be possible to start python.exe with >> a hidden console? >> >> Cheers, >> >> Angel >> >> >> On Sun, Sep 29, 2013 at 6:39 PM, Keegan Witt <[email protected]> >> wrote: >> > I think it's because they're not Python apps. The problem is if you >> call >> > Meld with pythonw.exe (which hides the command prompt), it doesn't wait >> for >> > the process to end before returning an exit code. The only way I've >> seen to >> > get an exit code is by calling with python.exe, which will create a >> command >> > prompt window. Another idea I had to avoid having 2 wrappers is to >> have the >> > first argument to the wrapper be some special maker to tell it to use >> > python.exe (and let the default be pythonw.exe), and have it eat that >> arg >> > before starting Meld with the rest of the args. Opinions? >> > >> > -Keegan >> > >> > >> > On Sat, Sep 28, 2013 at 4:10 AM, Angel Ezquerra < >> [email protected]> >> > wrote: >> >> >> >> That is a good point, but personally I would hate even more to get a >> >> command prompt every time I open the diff tool. >> >> >> >> Version Control Tools use diff such as meld for two things: diffing >> >> and merging. I don't think that tools usually need the exit code when >> >> using meld for diffing. For merging it would be nice to get the exit >> >> code though. Currently TortoiseHg will simply ask the user if the >> >> merge was successful, but with other tools this is not necessary. >> >> >> >> I don't quite understand why other tools (e.g. KDiff3, WinMerge) do >> >> not have this problem. These are GUI tools but they can keep >> >> TortoiseHg (or whoever calls the tool) waiting for the exit code until >> >> they are done, but they do not show a command prompt. Is this a >> >> fundamental problem in how meld is wrapped on windows? >> >> >> >> Cheers, >> >> >> >> Angel >> >> >> >> >> >> >> >> On Tue, Sep 24, 2013 at 4:10 PM, Keegan Witt <[email protected]> >> wrote: >> >> > That's true, but wouldn't you want tools like that to be aware of >> when >> >> > the >> >> > merging process has ended? If I call pythonw, it will appear to the >> >> > tool >> >> > calling the process that the process ended immediately. This also >> means >> >> > the >> >> > status code returned by pythonw is worthless since it will always be >> 0. >> >> > Isn't that an issue for these tools as well? Sorry for my >> ignorance, I >> >> > don't use Meld for that. >> >> > >> >> > I agree that it stinks that a separate window will now be opened, but >> >> > otherwise the calling process loses information about the status of >> the >> >> > process it called. I was thinking too of how this might be in a >> script >> >> > that >> >> > helps a user do some larger workflow. If it exits immediately >> (and/or >> >> > with >> >> > a worthless status code), the script wouldn't know whether to >> proceed or >> >> > not >> >> > with the next steps. >> >> > >> >> > -Keegan >> >> > >> >> > >> >> > On Tue, Sep 24, 2013 at 9:24 AM, Angel Ezquerra >> >> > <[email protected]> >> >> > wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> personally I think this change (calling python.exe rather than >> >> >> pythonw.exe) will be a serious regression when using meld with a >> tool >> >> >> such as TortoiseHg. TortoiseHg _always_ calls meld with parameters. >> >> >> This means that every time that you would use meld to diff or merge >> >> >> files from TortoiseHg (or any similar tool) you'd see a prompt >> window >> >> >> appear. >> >> >> >> >> >> Cheers, >> >> >> >> >> >> Angel >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Sep 24, 2013 at 10:35 AM, Keegan Witt <[email protected] >> > >> >> >> wrote: >> >> >> > Sorry for the delay. Someone reported that GTK wouldn't load for >> him >> >> >> > and I >> >> >> > was hoping to track that down why before updating the binaries. I >> >> >> > haven't >> >> >> > figured it out (it doesn't help that I've not been able to >> recreate >> >> >> > the >> >> >> > issue), but I've decided to go ahead and release new ones in the >> mean >> >> >> > time. >> >> >> > Has anyone else experienced this issue? Have an suggestions? >> I've >> >> >> > already >> >> >> > tried having him clear his path before calling the Python from >> >> >> > Portable >> >> >> > Python with the absolute paths (which didn't help), though he is >> able >> >> >> > to >> >> >> > run >> >> >> > the GTK demo. >> >> >> > >> >> >> > Besides the update to 1.8.1, I also now call python.exe instead of >> >> >> > pythonw.exe when calling meld.exe with parameters. This allows >> you >> >> >> > to >> >> >> > call >> >> >> > Meld from the commandline without pythonw exiting right away (the >> >> >> > only >> >> >> > downside being that a dialog box for python appears in that case >> -- >> >> >> > not >> >> >> > sure >> >> >> > there's really a way around this). When calling without >> parameters >> >> >> > (for >> >> >> > example from shortcuts), it continues to call pythonw. The issue >> >> >> > list >> >> >> > for >> >> >> > this installer release can be seen here. >> >> >> > >> >> >> > -Keegan >> >> >> > >> >> >> > >> >> >> > On Sat, Sep 21, 2013 at 7:08 PM, Kai Willadsen >> >> >> > <[email protected]> >> >> >> > wrote: >> >> >> >> >> >> >> >> Meld 1.8.1 has been released. >> >> >> >> >> >> >> >> >> >> >> >> Fixes: >> >> >> >> >> >> >> >> * Add AppData file (Kai Willadsen) >> >> >> >> * Change order of version control selection for CVS and old >> SVN >> >> >> >> (Kai >> >> >> >> Willadsen) >> >> >> >> * Fix escaped markup in folder comparisons (Kai Willadsen) >> >> >> >> >> >> >> >> Translations: >> >> >> >> >> >> >> >> * Daniel Mustieles (es) >> >> >> >> * Enrico Nicoletto (pt_BR) >> >> >> >> * Gabor Kelemen (hu) >> >> >> >> * Marek Černocký (cs) >> >> >> >> * Milo Casagrande (it) >> >> >> >> * Piotr Drąg (pl) >> >> >> >> >> >> >> >> >> >> >> >> This release can be downloaded from: >> >> >> >> >> >> >> >> http://download.gnome.org/sources/meld/1.8/meld-1.8.1.tar.xz >> >> >> >> >> >> >> >> >> >> >> >> What is Meld? >> >> >> >> ------------- >> >> >> >> >> >> >> >> Meld is a visual diff and merge tool. It lets you compare two or >> >> >> >> three >> >> >> >> files, >> >> >> >> and updates the comparisons while you edit them in-place. You can >> >> >> >> also >> >> >> >> compare >> >> >> >> folders, launching comparisons of individual files as desired. >> Last >> >> >> >> but >> >> >> >> by >> >> >> >> no >> >> >> >> means least, Meld lets you work with your current changes in a >> wide >> >> >> >> variety of >> >> >> >> version control systems, including Git, Bazaar, Mercurial, >> >> >> >> Subversion >> >> >> >> and >> >> >> >> CVS. >> >> >> >> _______________________________________________ >> >> >> >> meld-list mailing list >> >> >> >> [email protected] >> >> >> >> https://mail.gnome.org/mailman/listinfo/meld-list >> >> >> > >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > meld-list mailing list >> >> >> > [email protected] >> >> >> > https://mail.gnome.org/mailman/listinfo/meld-list >> >> > >> >> > >> > >> > >> > >
_______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
