Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Mihail Atanassov wrote: > >> The hotfix application example uses `git merge --no-commit` to apply >> temporary changes to the working tree during a bisect operation. In some >> situations this can be a fast-forward and `merge` will apply the hotfix >> branch's commits regardless of `--no-commit` (as documented in the `git >> merge` manual). >> >> In the pathological case this will make a `git bisect run` invocation >> loop indefinitely between the first bisect step and the fast-forwarded >> post-merge HEAD. >> >> Add `--no-ff` to the merge command to avoid this issue. > > Makes sense. > >> Changes since v1: >> - removed comment change > > This kind of note, that doesn't need to be recorded in the Git commit > history, should go after the "---" marker. See [1]: Thanks for mentoring. No need to resend as I can edit it out while queuing. Thanks both. > > You often want to add additional explanation about the patch, other > than the commit message itself. Place such "cover letter" material > between the three-dash line and the diffstat. For patches requiring > multiple iterations of review and discussion, an explanation of > changes between each iteration can be kept in Git-notes and inserted > automatically following the three-dash line via `git format-patch > --notes`. > >> Signed-off-by: Mihail Atanassov <m.atanassov92@xxxxxxxxx> >> --- >> Documentation/git-bisect.txt | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > Except for that one nit, > Reviewed-by: Jonathan Nieder <jrnieder@xxxxxxxxx> > > Thanks. > > [1] https://www.kernel.org/pub/software/scm/git/docs/SubmittingPatches.html#send-patches
