Re: Meld 1.7.1 released

[Nick <nospam codesniffer com>]

(Thinking out loud here...)

I'm reminded of KDiff3's behavior w/ this.  I don't remember what it
does w/ the exit code, but when merging a file (baseless or from a
base), only the output pane is editable--the others are read-only.  So
from that perspective, saving the output pane is less ambiguous.  But
IIRC, it also prompts to save and exit before closing the merge, which
was a subtle reminder for me of what will happen next.

So, would this situation be simplified if Meld made all but one pane
read-only when merging?  I'm not sure how feasible this is for users.  I
know that I sometimes use Meld to sync changes between files which
involves saving to more than one pane.  KDiff3 limits the user in this
way.


On Thu, 2013-04-04 at 06:20 +1000, Kai Willadsen wrote:
> On 3 April 2013 08:16, Angel Ezquerra <angel ezquerra gmail com> wrote:
> > On Tue, Apr 2, 2013 at 10:10 PM, Kai Willadsen <kai willadsen gmail com> wrote:
> > > On 3 April 2013 06:06, Angel Ezquerra <angel ezquerra gmail com> wrote:
> > > > On Tue, Apr 2, 2013 at 9:50 PM, Kai Willadsen <kai willadsen gmail com> wrote:
> > > > > On 3 April 2013 02:01, Keegan Witt <keeganwitt gmail com> 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?
> > >
> > > Not a portable python problem I think. We don't ever (to my
> > > recollection) change return values. I'm not sure that it makes sense
> > > to do so either, since there's no way to indicate multiple returns
> > > (i.e., tabs 1 and 3 were saved but tab 2 wasn't). I realise that
> > > launching multiple merges isn't a common case, but... it just feels
> > > wrong to me.
> > >
> > > Could you explain why you consider the checkchanged option to be a band-aid?
> > >
> > > cheers,
> > > Kai
> >
> > It is a band-aid because we only use that option when the tool is not
> > able to tell us that the merge was successful. Most merge tools do
> > tell us when a merge succeeded by returning a 0 exit code, and when
> > the merge fails with a non zero exit code. This allows us to do the
> > merge pretty much automatically. If the merge tool does not return a
> > non zero exit code when the merge is aborted by the user then we can
> > only guess, and we do so by checking if the merge file contents
> > changed, which is not very accurate. If they did not change we must
> > ask the user to confirm that the merge was successful, which adds an
> > additional prompt.
> >
> > So as you see it is less than ideal. One of the main mercurial devs,
> > while discussing the need to use the checkchanged setting said "That's
> > a very serious issue", and I agree with him.
>
> What I don't understand is how you expect *Meld* to know whether the
> merge was successful? I mean, it's pretty easy to exit(1) if the user
> doesn't save the merge file, but I don't see how that's significantly
> more accurate than checking the file contents on the Mercurial side?
>
> As I see it, the only other option is to require the user to click a
> "Yep, I resolved this" button, which is functionally the same as a
> command-line prompt saying "How did the merge go?".
>
> > BTW, if I understood you correctly, this is non windows specific, right?
>
> I haven't actually checked behaviour, but yes. There is no sensible
> way right now for us to set a return code based on a single
> comparison, simply because a window can contain multiple comparisons,
> and we would have no idea what to return.
>
> > I think that meld could handle the situation that you mention by
> > returning 0 if the user saves any of the files, and non zero
> > otherwise.
>
> That sounds exceedingly dangerous. If you open up two merges and only
> save one of them, then you're giving back a false positive, which is
> much scarier than saying that a merge failed when it didn't really.
>
> > Another option would be to only return 0 if the output file
> > (as specified with the -o parameter) is saved.
>
> Same as above I think.
>
> > What do you think?
>
> I'm certainly not averse to making changes to make Meld more usable by
> Mercurial, but it has to not break current Meld use. At this stage, it
> sounds to me like Mercurial (and maybe other systems? I don't know)
> would like Meld to have a completely different mode from the normal
> user-invoked one. Off the top of my head:
>
>  * Disallow creation of new tabs
>  * Disallow re-use of an existing instance
>  * Add exit code based on 'success of merge' (whatever that means)
>  * Some UI to indicate merge success?
>  * Remove file selectors, replacing them with labels
>
> ...all of which is doable. It's just work. If there's anyone lurking
> who is involved in mergetool configurations for Git or Bazaar or
> whatever, now would be a good time to speak up.
>
> cheers,
> Kai
> _______________________________________________
> meld-list mailing list
> meld-list gnome org
> https://mail.gnome.org/mailman/listinfo/meld-list