1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
================
Making a patch
================
You've discovered a bug or something else you want to change
in nipype_ .. |emdash| excellent!
You've worked out a way to fix it |emdash| even better!
You want to tell us about it |emdash| best of all!
The easiest way is to make a *patch* or set of patches. Here
we explain how. Making a patch is the simplest and quickest,
but if you're going to be doing anything more than simple
quick things, please consider following the
:ref:`git-development` model instead.
.. _making-patches:
Making patches
==============
Overview
--------
::
# tell git who you are
git config --global user.email you@yourdomain.example.com
git config --global user.name "Your Name Comes Here"
# get the repository if you don't have it
git clone git://github.com/nipy/nipype.git
# make a branch for your patching
cd nipype
git branch the-fix-im-thinking-of
git checkout the-fix-im-thinking-of
# hack, hack, hack
# Tell git about any new files you've made
git add somewhere/tests/test_my_bug.py
# commit work in progress as you go
git commit -am 'BF - added tests for Funny bug'
# hack hack, hack
git commit -am 'BF - added fix for Funny bug'
# make the patch files
git format-patch -M -C master
Then, send the generated patch files to the `nipype
mailing list`_ |emdash| where we will thank you warmly.
In detail
---------
#. Tell git_ who you are so it can label the commits you've
made::
git config --global user.email you@yourdomain.example.com
git config --global user.name "Your Name Comes Here"
#. If you don't already have one, clone a copy of the
nipype_ repository::
git clone git://github.com/nipy/nipype.git
cd nipype
#. Make a 'feature branch'. This will be where you work on
your bug fix. It's nice and safe and leaves you with
access to an unmodified copy of the code in the main
branch::
git branch the-fix-im-thinking-of
git checkout the-fix-im-thinking-of
#. Do some edits, and commit them as you go::
# hack, hack, hack
# Tell git about any new files you've made
git add somewhere/tests/test_my_bug.py
# commit work in progress as you go
git commit -am 'BF - added tests for Funny bug'
# hack hack, hack
git commit -am 'BF - added fix for Funny bug'
Note the ``-am`` options to ``commit``. The ``m`` flag just
signals that you're going to type a message on the command
line. The ``a`` flag |emdash| you can just take on faith |emdash|
or see `why the -a flag?`_.
#. When you have finished, check you have committed all your
changes::
git status
#. Finally, make your commits into patches. You want all the
commits since you branched from the ``master`` branch::
git format-patch -M -C master
You will now have several files named for the commits::
0001-BF-added-tests-for-Funny-bug.patch
0002-BF-added-fix-for-Funny-bug.patch
Send these files to the `nipype mailing list`_.
When you are done, to switch back to the main copy of the
code, just return to the ``master`` branch::
git checkout master
Moving from patching to development
===================================
If you find you have done some patches, and you have one or
more feature branches, you will probably want to switch to
development mode. You can do this with the repository you
have.
Fork the nipype_ repository on github_ |emdash| :ref:`forking`.
Then::
# checkout and refresh master branch from main repo
git checkout master
git pull origin master
# rename pointer to main repository to 'upstream'
git remote rename origin upstream
# point your repo to default read / write to your fork on github
git remote add origin git@github.com:your-user-name/nipype.git
# push up any branches you've made and want to keep
git push origin the-fix-im-thinking-of
Then you can, if you want, follow the
:ref:`development-workflow`.
.. include:: links.inc
|
