On Wed, Nov 18, 2009 at 08:28:33PM +0200, Alan Barrett wrote: > On Wed, 18 Nov 2009, Stefan Sperling wrote: > > On Wed, Nov 18, 2009 at 08:47:51AM +0200, Alan Barrett wrote: > > > On Mon, 16 Nov 2009, Stefan Sperling wrote: > > > > 5) Hunks are only applied if they do not overlap with any other hunk. > > > Other patch implementations are able to deal with overlapping hunks. > [example snipped] > > > > I can see that applying overlapping hunks could be made to work in > > theory. But when do people use such patches in practice? > > Would gnu diff or svn diff ever produce anything like the example on > > the left? > > I think I have seen overlapping context diffs from a very old version > of diff. Of course the overlap was only in the leading and trailing > context lines. I don't think current versions of gnu diff or svn diff > will produce them. I have created such patches by hand occasionally > (by splitting up a more conventional patch that was failing to apply).
I had hand-edited patches in mind to some degree. In the scheme we're considering you could add, change, or delete lines from a hunk without adjusting the hunk header and it should still work, provided of course that the changes don't cause hunks to overlap. > The algorithm you presented earlier could, I think, easily be modified > to keep track of the number of lines of leading and trailing context in > each hunk, and then allow the leading context of one hunk to overlap > the trailing context of another hunk, or vice versa, but never allow > overlaps that involve the "core" of any hunk (where "core" is defined as > what's left after the leading and trailing context is removed). Whether > it's worth the effort is another question. Good point. It is something to keep in mind for later. Note that ignoring some leading and trailing lines of context is a matter of "fuzziness", something which even basic UNIX patch provides and which could be useful for svn to do as well. So this is not as far out the window as my statement made it sound. > > > An interactive patch assistant or conflict resolution tool might > > > want to offer the option of splitting a hunk into two or more > > > smaller hunks and re-trying each smaller hunk. "git add --patch" > > > offers something like this in a different context (getting ready > > > to commit a subset of the changes to a file). > > > > Right now I'm aiming for basic, but solid, patch support. Nothing fancy. > > I wasn't suggesting that you should implement any kind of interactive > patch assistant, but I was trying to show a plausible use case for > overlapping hunks. Oh, I would love such a feature :) I'm just trying not to lose focus on getting the basics done properly first. Thanks, Stefan
