This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 121788 - User friendly tool for merging
Summary: User friendly tool for merging
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: issues@versioncontrol
Keywords: RELNOTE
Depends on:
Reported: 2007-11-13 09:33 UTC by novakm
Modified: 2008-01-03 09:39 UTC (History)
0 users

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description novakm 2007-11-13 09:33:29 UTC
In current state if Import patches would cause conflict it creates a <filename>.rej file. Some userfriendly way to
resolve it would be nice. Maybe something like in CVS and SVN. It should merge the .rej file with your local file
resulting (after your intervention) into locally modified file and disappearing the .rej file.
Comment 1 novakm 2007-11-19 09:59:37 UTC
Generalized Summary field. After patch there can be .rej, .orig and the file with partially applied changes. Merging
tool using these three files would help a lot.
Comment 2 John Rice 2007-12-03 16:25:46 UTC
I've been looking into this:

When Mercurial does the Import Diff, it tries to do an automated merge using the input from the specified Patch file in
standard diff format.

"If patch cannot find a place to install a hunk of the patch, it writes the hunk out to a reject file (see Reject Names,
for information on how reject files are named). It writes out rejected hunks in context format no matter what form the
input patch is in."

Looking at the code in place to do the Resolve Conflicts in ResolveConflictsExecutor, you can see that it is taking as
input a diff file generated from an attempted merge and splitting it up into the various diff portions to allow the
Resolve Conflicts UI to display the parts in conflict for the user to choose.
The problem with the .rej files is that they have been rejected by this merge process and so may or may not have a
location which makes sense to merge them into.

The simplest and safest approach is to diff the orig and new file that may have some hunks already successfully merged
and then look at the .rej file to see roughly where you need to put the changes and then do so by hand.

I cannot see any straightforward way to modify the ResolveConflicts code to handle .rej file as input which would be
reliable. As the above quote says the Patch tool has rejected the hunk because it couldn't find somewhere sensible to
put it.

Update from the Unofficial Mercurial Dev Guide:
Strategies for applying a patch:

Exact Match with context, line numbers and text: Hunk applied.
Exact Match with context and text, ignore line numbers: Print out offset from original line number.
Reduced context and text: Print applied hunk with fuzz factor.
If none work: Hunk rejected, unmodified file saved with .orig, copy of file with hunks that did apply and .rej with
rejected hunks.

Handling rejection:
Unfortunately, there aren’t any great techniques for dealing with rejected hunks. Most often, you’ll need to view the
.rej file and edit the target file, applying the rejected hunks by hand. There is an experimental tool that might help
called mpatch.

The mpatch command can help with four common reasons that a hunk may be rejected:
    * The context in the middle of a hunk has changed.
    * A hunk is missing some context at the beginning or end.
    * A large hunk might apply better—either entirely or in part—if it was broken up into smaller hunks.
    * A hunk removes lines with slightly different content than those currently present in the file.
mpatch enforces double-checking the tool’s output, by automatically dropping you into a merge program when it has done
its job, so that you can verify its work and finish off any remaining merges. 

Will investigate mpatch and see if we could launch it or set it as the default patch tool, so if .rej files are
generated we'd launch a 3 way diff tool if available to help manage the rejects.
Comment 3 John Rice 2007-12-03 16:49:35 UTC
Location of mpatch:
Comment 4 John Rice 2007-12-04 16:44:45 UTC
Looked into mpatch and as its python code will run on the supported platforms. The problem is that it does not generate
the  type of forced merge with diff inserts that I'd need if we wanted to use the internal Resolve Executor in the plugin.

Closing this with no plan to fix and release noting the issue with details about mpatch if folks want to run this