Yamyam: 1版をインポートしました

2018-06-28T17:49:55Z

1版をインポートしました

2018年5月13日 (日) 12:48にwiki>Mont29による

2018-05-13T12:48:44Z

新規ページ

=Patches and Diffs=

==What is a patch?==
A patch is no more than a text file which contains data about the differences between two versions of code. They contain changes to code, adding functionality, fixing a bug, etc. A patch contains information about which files change on which lines and how. [[Dev:Doc/Process/Contributing_Code|Contributing Code to Blender]] is done through such ''patches'' or ''diffs''.

The words ''patch'' and ''diff'' are often used interchangeably, although for Git they can mean slight different things. Our Code Review tool currently accepts diffs created with <tt>git diff</tt> or <tt>git show</tt>, not <tt>git format-patch</tt>.

====When should I submit a patch?====
Writing patches is generally done for two reasons:

* '''To distribute a bugfix''': often you may spot a bug in Blender's source code before a developer has the opportunity to do the same work. Creating a patch is the perfect opportunity to get the work done without putting it on someone else's (likely very long) todo list.

* '''Contributing new features''': many coders take it upon themselves to add functionality to Blender in their own free time. Without these 'homebrew' projects, Blender would not be what it is today. Outside contributions from hobbyists and professionals alike are crucial to the development process. Yes that means you!

==Applying Patches==

In order to apply the changes stored in a patch file to your checkout of the source code you need to use the following command in your repository root directory. Note: the following require that patch is installed.

<source lang="bash">
# for git diffs
patch -p1 < some-new-feature.diff
</source>

<source lang="bash">
# for svn diffs (older patches in the tracker)
patch -p0 < some-new-feature.diff
</source>

You will then be given an indication of whether or not the operation was a success. If it was not, there are many possibilities as to why your source code was incompatible with the source code the patch was created against. It is best to contact the author to be sure you both have an updated version of sources or edit the resulting files manually to be sure everything is as it should be. Be warned! This can be a time consuming and frustrating process.

==Reverting Patches==

You can revert the changes made by a patch by using the -R switch as shown below, again from the root directory:

<source lang="bash">
# for git diffs
patch -p1 -R < some-new-feature.diff
</source>

<source lang="bash">
# for svn diffs (older patches in the tracker)
patch -p0 -R < some-new-feature.diff
</source>

==Creating Patches==

The simplest way is simply to make changes in the code, then run this command from the root repository directory. You can then upload this file and share it with others.

<source lang="bash">
git diff > some-new-feature.diff
</source>

==Creating Patches from Local Git Branches==

When working with Git, the usual workflow is to create local branches where you commit your changes. You can then easily switch between the unmodified master branch and your local branch, and create a diff from the local branch when you're ready to submit it.

To create a new branch when you are in the <tt>master</tt> branch, the basic commands are:

<source lang="bash">
git checkout -b some-new-feature
# ... make changes to code ...
git commit -a
</source>

To generate a diff, you can run:
<source lang="bash">
# generate a diff
git diff master..some-new-feature > some-new-feature.diff
</source>

If you work on your <tt>some-new-feature</tt> branch but do not submit its diff soon, it can get out of sync with the <tt>master</tt> branch, where you typically keep pulling in commits with new features and bugfixes from the main repository. If you are going to do further work on the new feature or send a diff, you want it to be created relative to the very latest version of the main repository. Otherwise your diff may no longer apply cleanly for others, or your feature may no longer work correctly due to changes in the code.

To get all those new commits into your <tt>some-new-feature</tt> branch as well, you have to 'rebase' it on top of <tt>master</tt>. That means it will pull in new commits from <tt>master</tt> and keep your local commits at the top of the commit list.

<source lang="bash">
# switch to feature branch
git checkout some-new-feature
# rebase on top of master
git rebase master
# now you can continue work on the feature or generate a new diff
</source>

For more info on how to use Git or how to submit changes for code review, see the [[Dev:Doc/Tools/Git|Git Usage]] and [[Dev:Doc/Tools/Code_Review|Code Review]] pages.

==Git Mailbox Style Patch Sets==

With Git you can create more advanced patches that can contain multiple commits and information about the author. Unfortunately our code review tool does not accept these yet, for that you have to use the <tt>arc</tt> command line tool described on the code review documentation.

For reference, here is how to use such patches. To apply:

<source lang="bash">
# for git mailbox style patch sets
git am group-of-patches.mbx
</source>

To create patches in mailbox style format from changes in a branch:

<source lang="bash">
git format-patch --stdout origin > group-of-patches.mbx
</source>

To generate a mailbox style patch from commits R1 to R2:

<source lang="bash">
git format-patch --stdout R1..R2 > group-of-patches.mbx
</source>

← 古い版	2018年6月28日 (木) 17:49時点における版
(相違点なし)

Dev:Doc/Tools/Patches - 版の履歴

Yamyam: 1版 をインポートしました

2018年5月13日 (日) 12:48にwiki>Mont29による

Yamyam: 1版をインポートしました