@@ -121,6 +121,49 @@ Here's a typical workflow for triaging a newly opened issue.
121
121
unless it's know that this issue should be addressed in a specific release (say
122
122
because it's a large regression).
123
123
124
+ .. _maintaining.regressions :
125
+
126
+ Investigating regressions
127
+ -------------------------
128
+
129
+ Regressions are bugs that unintentionally break previously working code. The common way
130
+ to investigate regressions is by using
131
+ `git bisect <https://git-scm.com/docs/git-bisect >`_,
132
+ which finds the first commit that introduced the bug.
133
+
134
+ For example: a user reports that ``pd.Series([1, 1]).sum() `` returns ``3 ``
135
+ in pandas version ``1.5.0 `` while in version ``1.4.0 `` it returned ``2 ``. To begin,
136
+ create a file ``t.py `` in your pandas directory, which contains
137
+
138
+ .. code-block :: python
139
+
140
+ import pandas as pd
141
+ assert pd.Series([1 , 1 ]).sum() == 2
142
+
143
+ and then run::
144
+
145
+ git bisect start
146
+ git bisect good v1.4.0
147
+ git bisect bad v1.5.0
148
+ git bisect run bash -c "python setup.py build_ext -j 4; python t.py"
149
+
150
+ This finds the first commit that changed the behavior. The C extensions have to be
151
+ rebuilt at every step, so the search can take a while.
152
+
153
+ Exit bisect and rebuild the current version::
154
+
155
+ git bisect reset
156
+ python setup.py build_ext -j 4
157
+
158
+ Report your findings under the corresponding issue and ping the commit author to get
159
+ their input.
160
+
161
+ .. note ::
162
+ In the ``bisect run `` command above, commits are considered good if ``t.py `` exits
163
+ with ``0 `` and bad otherwise. When raising an exception is the desired behavior,
164
+ wrap the code in an appropriate ``try/except `` statement. See :issue: `35685 ` for
165
+ more examples.
166
+
124
167
.. _maintaining.closing :
125
168
126
169
Closing issues
0 commit comments