(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 <[email protected]> wrote: > > On Tue, Apr 2, 2013 at 10:10 PM, Kai Willadsen <[email protected]> > > wrote: > >> On 3 April 2013 06:06, Angel Ezquerra <[email protected]> wrote: > >>> 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? > >> > >> 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 > [email protected] > https://mail.gnome.org/mailman/listinfo/meld-list _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
