I want to learn to patch

[James Richard Tyrer]

Chuck Robey wrote:
> James Richard Tyrer wrote:
>> First I admire your enthusiasm.  Do not take offense at my rather direct 
>> engineer's analysis.
>>
>> Dotan Cohen wrote:
>>> Here is a very simple bug, that I want to learn to submit patches with:
>>> https://bugs.kde.org/show_bug.cgi?id=188383
>>>
>> I have to warn your that there have been major arguments about this 
>> issue and I have rather strong opinions about it.  We won't worry about 
>> my opinions but expect to run into some resistance.
>>
>>> I have googled KDE Development and found lots of tutorials from KDE 2
>>> and KDE 3, and lots of tutorials about setting up what seems to be a
>>> very complex and error-prone development environment. However, as one
>>> can simply view the code online [1] I would like to work this way. I
>>> looked around the websvn tree for the file(s) that contain the string
>>> "Other Tabs" from the bug in question, but I could not find them. So I
>>> have these two questions:
>>>
>>> 1) How does one go about finding the correct file(s) to modify?
>> This is probably part of the Konqueror code:
>>
>> 	KDEBase:Apps:Konqueror
>>
>> in SVN.  You can find the relevant files using "Find File" looking for 
>> "*.*c*" with a string in: "Context::Containing Text" or use Grep 
>> (command line) in  Konsole.
>>
>>> 2) How does one make a diff file?
>> First, you need to checkout and build the KDEBase module from SVN:
>>
>> svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase
>>
>> Well actually, you need to install subversion, the GNU C/C++ compiler, 
>> and CMake.  I would suggest reading the relevant (user/client) parts of:
>>
>> 	http://svnbook.red-bean.com/
>>
>> Now, having found what needs to be changed:
>>
>> 1.  Change it.
>> 2.  Compile and install.
>> 3.  Test to see that it works like you want (if not go back to #1)
>> 4.  Execute: "svn status" to see that all is well
>> 5.  Execute: "svn up" to see that there is no conflict
>> 6.  Execute: "svn diff" to see your patch.
>> 7.  If you want a patch file, Execute: "svn diff > file.diff
>> 8.  Post your patch to the "kde-devel" (subscribe to it) mailing list
>>      with the Subject starting with "[PATCH]" or attach the diff file to
>>      the bug and label the attachment as a Patch.
>>
>> So, that is a basic outline.  I expect that you might have further 
>> questions.
>>
> 
> 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.
> 
I intended this as a basic outline and thought that he would probably 
have more questions when he actually got down to doing things.

> 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.

I have been using the internal subversion: "svn diff" command lately 
rather than the command line utility.  It only has one type of output, 
although you can use the diff command line utility with it -- at least 
the fine manual says you can (I have never tried it).

You are correct that you need to give options when using the command 
line diff utility.  IIRC, "diff -Naur <old_file> <new_file>" is the 
preferred form and the output file should have the extension 'patch'.

-- 
JRT

Linux (mostly) From Scratch

___________________________________________________
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.