From: horst.h.von.brand@inf.utfsm.cl Date: Sat, 03 Jun 2006 20:27:15 GMT Subject: [PATCH 16/27] Documentation: Spelling fixes Message-ID: <6743.52590363032$1149366518@news.gmane.org> In-Reply-To: <1149366483572-git-send-email-> From: Horst H. von Brand Signed-off-by: Horst H. von Brand --- Documentation/git-read-tree.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt index 844cfda..02c7e99 100644 --- a/Documentation/git-read-tree.txt +++ b/Documentation/git-read-tree.txt @@ -205,7 +205,7 @@ The `git-write-tree` command refuses to will complain about unmerged entries if it sees a single entry that is not stage 0. -Ok, this all sounds like a collection of totally nonsensical rules, +OK, this all sounds like a collection of totally nonsensical rules, but it's actually exactly what you want in order to do a fast merge. The different stages represent the "result tree" (stage 0, aka "merged"), the original tree (stage 1, aka "orig"), and the two trees @@ -226,7 +226,7 @@ populated. Here is an outline of how th - the index file saves and restores with all this information, so you can merge things incrementally, but as long as it has entries in - stages 1/2/3 (ie "unmerged entries") you can't write the result. So + stages 1/2/3 (i.e., "unmerged entries") you can't write the result. So now the merge algorithm ends up being really simple: * you walk the index in order, and ignore all entries of stage 0, -- 1.3.3.g86f7