X-Git-Url: https://git.tokkee.org/?a=blobdiff_plain;ds=sidebyside;f=Documentation%2Fgit-bisect-lk2009.txt;h=efbe3790bb4a0521c954650ad43075f583500c7b;hb=316fa401e1c953ffc80533aaf6839817595cdd77;hp=6b7b2e5497584489c8c3a50b621f0835ad9e34b7;hpb=a42332c21723fde9f36b579f6b39a23aa1aac137;p=git.git

diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt
index 6b7b2e549..efbe3790b 100644
--- a/Documentation/git-bisect-lk2009.txt
+++ b/Documentation/git-bisect-lk2009.txt
@@ -799,7 +799,7 @@ fixed in the "main" branch by commit "F"?
 The result of such a bisection would be that we would find that H is
 the first bad commit, when in fact it's B. So that would be wrong!
 
-And yes it's can happen in practice that people working on one branch
+And yes it can happen in practice that people working on one branch
 are not aware that people working on another branch fixed a bug! It
 could also happen that F fixed more than one bug or that it is a
 revert of some big development effort that was not ready to be
@@ -971,7 +971,7 @@ logical change in each commit.
 The smaller the changes in your commit, the most effective "git
 bisect" will be. And you will probably need "git bisect" less in the
 first place, as small changes are easier to review even if they are
-only reviewed by the commiter.
+only reviewed by the committer.
 
 Another good idea is to have good commit messages. They can be very
 helpful to understand why some changes were made.