On Tue, Apr 2, 2013 at 9:50 PM, Kai Willadsen <[email protected]> wrote: > On 3 April 2013 02:01, Keegan Witt <[email protected]> wrote: >> I exceeded my Dropbox public folder limits, the new home for them is here: >> https://meld-installer.googlecode.com/files/meld-0.0.0.0.exe >> https://meld-installer.googlecode.com/files/meld-0.0.0.0.zip >> I'll keep these around permanently and periodically update them with the >> latest from Git master. I include the .git directory, so you can do a git >> pull on the meld directory at any time if you want to update it yourself. >> >> This seems like an important issue to get fixed. Do you think it'd be >> appropriate to push out another release sooner rather than later? > > Yeah, could do. I'll see if I can find time this weekend for it. For > that to happen, I'd appreciate any testing that people might want to > throw at current git. Several Windows-related fixes went in over the > weekend for Git actions, temp files and executable locating, and it > would be nice if they worked for someone other than me. > > cheers, > Kai
There is a serious issue on Windows that we've been discussing on the mercurial-devel mailing list, which is that meld returns 0 even if you do not save the merge output (i.e. if the merge fails). This makes mercurial believe that the merge was successful when it isn't. For now we are thinking of enabling mercurial's "checkchanged" option for meld, which means that mercurial will check if the merge output changed once meld exits, and ask the user if the merge failed if it did not. That is a band-aid though, so improvements on that area would be really great. I think Keegan is aware of that issue. Something related to portable python? Cheers, Angel _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
