Re: xxdiff as a visual diff tool (shameless plug)

[Martin Blais]

On Friday 22 March 2002 04:27, Pavel Machek wrote:
> Hi!
>
> > I actually wanted to implement it exactly like this in xxdiff,
> > and I think it may not be too hard. Something like
> >
> >   "xxdiff --patch file1 < patch"
> >
> > and it would display as two files, and allow you to save merged
> > results. That was the plan (read more below).
> >
> > I wanted to spawn a patch command on it and recuperate the
> > output and then run diff and display that, so one could use and
> > alternate patch program as well, and I would reuse patch's
> > heuristics automatically (e.g. i don't have to code it myself).
>
> ... but ...
>
> > > Neil Brown agreed with this, and said, "I would like a tool
> > > (actually an emacs mode) that would show me exactly why a patch
> > > fails, and allow me to edit bits until it fits, and then apply
> > > it. I assume that is what you mean by "wiggle a patch into a
> > > file"." Pavel Machek also thought this would be a rerally great
> > > thing.
> >
> > The part I haven't figured out a nice solution for yet, is for
> > the failed hunks... how to display them sensibly.  I was
> > thinking of using the 3-file display with the third file
> > showing only the failed hunks in the approximate location where
> > they were supposed to be. Not sure how to do this yet. Any
> > ideas welcome.
>
> It would be great to somehow split patches before feeding them to the
> patch. If you have one big hunk, and it fails because of one letter
> added somewhere in file, it is *big pain* to find/kill offending
> letter.

i though patch did that by itself, by attempting to merge per-hunk, and that 
it saved all the failed merges in a reject file (file.rej). or perhaps 
i'm missing something. isn't it the case?

(note that i don't have much experience using patch itself)