On Thu, Jun 27, 2013 at 11:53 PM, Kai Willadsen <[email protected]> wrote: > > On 28 June 2013 00:44, Gilboa Davara <[email protected]> wrote: > > On Thu, Jun 27, 2013 at 5:21 PM, Chuck Tuffli <[email protected]> wrote: > >> I suspect this is the same issue Kai fixed recently for me. Give a > >> directory structure like: > >> > >> a/ > >> b/foo.c > >> c/bar.c > >> > >> meld would generate the error you mention if both foo.c and bar.c had > >> modifications. The fix (e79f5611799d0cd88e8ec630b699d9027503a45c I > >> think) in git fixed the problem I was seeing. > >> > >> --chuck > > > > I rather not pull git right now. > > > > Kai, > > > > Just to be certain: Should I simply comment out > > self.vc.uncache_inventory() in _search_recursively_iter? > > Chuck is right, this looks like exactly the same problem. So yeah, > that's what I'd try. > > The behaviour this change fixes is that running a comparison in a > different subdirectory to the first comparison that's run, breaks. > > cheers, > Kai
Seems to work just fine. Thanks. Should I contact the Fedora meld maintainer and get the fix applied to the official package, or should I simply wait for 1.7.4? - GIlboa _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
