* Ok, it works on WC:s with changes as well, but sometimes the changes on the WC will have a hard time surviving going back in time. It could be an option (or part of a new, more user friendly patch dialog (as suggested (much) earlier), ) when applying a patch to do the above mentioned steps automatically. I guess it would make sense to automate this. I'm regularly following the following pattern when applying patches:ġ.) Open the patchfile in a text editor and check what revision that the patch was created on.Ģ.) Use "Update to revision." to move the working copy back to that revision. That was another, much simpler, suggestion that I was about to make, but refrained from since it doesn't (really*) work with "dirty" WC:s. > at their original position the patchfile indicates, so that's not > Since we don't have the original file we also can't just apply them In the process, more or less blindly, throwing away a bunch of lines which would be OK since the user will be presented with this "conflict" in a nice (and familiar) manner. In that case we could simply replace whatever that is present between the context start and end lines in the source with what would have been the result of the patch file. Maybe I'm just repeatedly hitting an edge case here, but almost invariably when I was applying the patches here the context lines of the hunks were still present in the code, maybe not on the expected row number, but pretty close. That is: Make a best guess where to apply the patch.
If we would give the result to a human operator for manual resolving, we could be much more aggressive.
It expects to find a matching "clean" place to apply the hunk. TMerge can't apply them and show a conflict, because they can'tīut the patch algorithm here is being conservative. > reason: the patch algorithm couldn't find a place where they could be > The problem is that the rejected hunks could not be applied, and for a > Would it be possible to use the three way "conflict" view instead? > patchfiles? Right now the rejected hunks are shown in a new window. > little bit more help when it comes to resolving conflicts in
> The question is: Would it make sense to let TortoiseMerge give a > modifications in the working copy conflicts with the data provided in This invariably leads to that some patches I have been doing some patch applying as of late, and some of them on