Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
diff -u file1.txt file2.txt > patchfile
creates a patch file which consists of instruction for patch to convert file1.txt to be exactly like file2.txt
Can't this be done using cp command instead? I can imagine this to be useful for when the file is too large and has to be transferred over a network where this approach might save bandwidth. Is there any other way to use diff/patch which would be advantageous in other scenarios?
Diffs can be more complicated than just comparing one file versus another. The can compare entire directory hierarchies. Consider the example that I want fix a bug in GCC. My change adds a line or two in 4 or 5 files and deletes a handful of lines in those and other files. If I want to communicate these changes to someone, potentially for inclusion into GCC my options are
Copying the entire source tree doesn't make sense, but what about the other two options, which gets at the core of your question. Now consider that someone else also worked on the same file as I did and we both give our changes to someone. How will this person know what we've done and if the changes are compatible (different parts of the file) or conflict (same lines of the file)? He will diff them! The diff can tell him how the files differ from each other and from the unmodified source file. If the diff is what is needed, it just makes more sense to just send the diff in the first place. A diff can also contain changes from more than one file, so while I edited 9 files in total, I can provide a single diff file to describe those changes.
Diffs can also be used to provide history. What if a change three months ago caused a bug I only discovered today. If I can narrow down when the bug was introduced and can isolate it to a specific change, I can use the diff to "undo" or revert the change. This is not something I could as easily do if I were only copying files around.
This all ties into source version control where programs may record files history as a series of diffs from the time it was created until today. The diffs provide history (I can recreate the file as it was on any particular day), I can see who to blame for breaking something (the diff has an owner) and I can easily submit changes to upstream projects by giving them specific diffs (maybe they are only interested in one change when I've made many).
In summary, yes, cp is easier than diff and patch, but the utility of diff and patch is greater than cp for situations where how files change is important to track.
When you get a patch you can often (that is unless you have made changes to the exact same lines) apply the patch to a set of files that you have changed yourself as well.
The patch has information about the old and the new state of the files. If you get a copied file you don't know what the original was (the old state) and you cannot apply the differences to a file (or set of files) that you have changed as well without great difficulty. So for sets of source files it is not the space preservation that is of major concern, it is the before-after information.
Before (context/unified) diffs this was often done with instructions for editors (insert a line after X, delete line Y), but that would only work if you knew the state these instruction started from. Thus having the same problem as your "solution" with just copying.
diff -u) are an improvement designed for humans, they don't help robustness against conflicts over regular context diff (diff -c), I think. Even plain diffs (diff) still often work without knowing exactly the "state these instruction started from". Nevertheless, this is better than the accepted answer because talking about how patch files can patch multiple source files at the same time is really a red herring.
If you are using diff, you can see what exactly has changed, so using diff/patch is a way to prevent someone from slipping unwanted changes in the file.
The changes made to the files are usually much smaller than the files being changed.
This means storing a diff can save you a lot of space. When diff was created, disk space was expensive.
But it also means you can reapply a diff to a file even when that file has changed in other ways. The patch utility will do that for you and tell you when there are problems.
This is in fact the most important reason to work with diffs in software development. When a change has been made (usually to more than one file), it can be saved as a diff: the result is called a change set or patch. If all is well, the patch is not just some arbitrary change, but it implements some kind of functional change - e.g. a bug fix or a new feature.
Meanwhile, a different change can be made, possibly by a different developer, even in a different location. If the changes weren't made to the same parts of the same files, they can then be applied independently. So the developers can send each other their patches for testing. A whole set of patches can build up that represents possible changes; some of these may ultimately be rejected, the rest will be integrated into the system.
So working with diffs allows concurrent development. You no longer have to work on one change at a time.
Modern distributed version control systems are a continuation of this way of working.
In short it can. If you watch some Thinkg Big Larry Wall videos on youtube, he talks about how diff/patch got started and what problems they solved, and in essence, it was about reducing size for communication over the internet while keeping the patches flexible and human-readable.
If you're on a local system and don't care about any of these things, then cp or rsync are fine.
