I want to learn to patch

Dotan Cohen dotancohen at gmail.com
Sat Jun 6 15:52:55 BST 2009

> Nothing you say here is wrong, but I thought it would make sense to *some* folks
> to describe one part a bit more closely (with the idea that this is gonna be
> bait for would-be coders via Google).  I'm not criticizing here, please note that.
> First, there are a group of different forms that diff can be coaxed into
> producing.  They all do actually work, but some forms are easier for humans to
> read, and more obvious to catch errors in, than others forms, so a convention
> has been formed for a lot of projects (certainly, this includes FreeBSD and KDE)
> to require that all diff runs to use the "unified" form.  Among other
> parameters, just include -u to diff (as opposed to -c for context type, or even
> the default kind which is the "edit" form.  Both the "edit" and "context" diff
> outputs will get you yelled at (even though they work), and if you run them on
> purpose (just so you can view the outputs yourself) I think the reason that
> folks want you to use the unified diff will be obvious to you (as a human,
> supposedly...).
> The 2nd point which I think might be confusing is the order that you give the
> files to diff  on the command line in.  One is called the original, the other is
> our changed data.  If you're not using a system like KDE, or FreeBSD, or
> anything that wraps your diffs for you so you are more likely to get it correct,
>  then you need to worry a bit more about file order, because you're going to be
> giving the diff command directly.   First, you want to have a copy of the form
> of the file you're going to be changing, before any mods go into it.  My habit
> is to copy the original of any file I'm intending to modify to a file of the
> same name, but with a suffix of ".orig"  Well, the the point I'm going to make
> is, that the order that you give the files to diff is very important.  In KDE,
> where svn is handling your diff calls for you, you can ignore this point, but if
> other systems, the trick to remember is, to always give the file original form
> to the diff first, and after that, the modified file.  You mustn't get the order
> incorrect, because if you do, "patch" is going to ask you if your patch might be
> reversed.  So, if you get that response from "patch", remember you always give
> the original file first, THEN the modified file.  The output is what patch has
> been created to read, directly.

Thank you. Even if I do not need to worry about it now, properly
understanding the diff utility and the expected conventions in a
general sense will certainly help in the future. Thanks!

Dotan Cohen

This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

More information about the kde mailing list