![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
The patch utility
Jun. 5th, 2013 09:45 amI think I can remember when I first learned about the diff and patch utilities, but I was a lot younger then. Even though it was so very long ago, context diffs were the norm and so I learned about them at the same time as I learned about these utilities.
What I didn't learn...or at least didn't learn very well...was that the context part of the diff is what matters. The patch utility uses the context to identify the location of the change, the line numbers just tell the patch utility where to start looking. Moreover, if the patch utility fails to find a location that precisely matches the context it will look for a less precisely matching context by ignoring the value of the outermost lines of the context in searching for a match.
What is the point of this very generous notion of a match? Well it's to aid developers who may be submitting a patch for a change generated wrt. a slightly different code base from the copy where the change is applied. If the patch utility had a more precise definition of a match then the developers submitting the patch would have to do their work on a codebase that precisely matches the code base to which the patch is applied. That would force a good deal of syncing on the part of the developer and make the whole process more onerous.
Of course, patch itself can be configured by means of the fuzz factor option to be less or more precise. A fuzz factor of 0 makes patch require a perfect match.
When is requiring a perfect match a good thing? Well, this all came up when I was working on updating a package for the yocto project. There were some patches that needed to be applied to the new version's configure script, and I updated the patches so that they were a precise match. If I hadn't updated them, however, they would have still been applied correctly as the configure script had not changed much between the versions. So, should patches like this be required to be a perfect match? The code to which they must be applied is known exactly, which is an argument for requiring precision. On the other hand, perfect precision places a burden on package maintainers who must remake these patches each time a version changes. Yet it's probably a good idea to require package maintainers to review and pay attention to those patches; after all they did have an original purpose which may become obsolete as the packages are updated. Requiring a perfect match would cause a bit more oversight. But, would it also be a large burden for a small benefit? Dunno.
Note that the quilt utility can be used to automate the process of updating patches making the whole thing less of a burden.
What I didn't learn...or at least didn't learn very well...was that the context part of the diff is what matters. The patch utility uses the context to identify the location of the change, the line numbers just tell the patch utility where to start looking. Moreover, if the patch utility fails to find a location that precisely matches the context it will look for a less precisely matching context by ignoring the value of the outermost lines of the context in searching for a match.
What is the point of this very generous notion of a match? Well it's to aid developers who may be submitting a patch for a change generated wrt. a slightly different code base from the copy where the change is applied. If the patch utility had a more precise definition of a match then the developers submitting the patch would have to do their work on a codebase that precisely matches the code base to which the patch is applied. That would force a good deal of syncing on the part of the developer and make the whole process more onerous.
Of course, patch itself can be configured by means of the fuzz factor option to be less or more precise. A fuzz factor of 0 makes patch require a perfect match.
When is requiring a perfect match a good thing? Well, this all came up when I was working on updating a package for the yocto project. There were some patches that needed to be applied to the new version's configure script, and I updated the patches so that they were a precise match. If I hadn't updated them, however, they would have still been applied correctly as the configure script had not changed much between the versions. So, should patches like this be required to be a perfect match? The code to which they must be applied is known exactly, which is an argument for requiring precision. On the other hand, perfect precision places a burden on package maintainers who must remake these patches each time a version changes. Yet it's probably a good idea to require package maintainers to review and pay attention to those patches; after all they did have an original purpose which may become obsolete as the packages are updated. Requiring a perfect match would cause a bit more oversight. But, would it also be a large burden for a small benefit? Dunno.
Note that the quilt utility can be used to automate the process of updating patches making the whole thing less of a burden.
