Author/Committer/Acks/Sign-offs
How reviews of patches are recorded is defined by each project. Git directly supports only two pre-defined identity fields: Author and Committer. Neither is wholly appropriate for marking reviews/acknowledgments. Git does have support additional for “Signed-off-by:” lines, but these are just regular text in the commit message (unlike the Author and Committer, which are managed by and assigned meaning by Git).
Like all parts of commit messages, the meaning of “Signed-off-by:” is up to each project to define. In the Git project, “Signed-off-by:” lines mean something like “I certify that this code is compatible with the license of this project” (see “Developer's Certificate of Origin” in Git's SubmittingPatches document). In the Git project, the “Acked-by:” lines mean something like “I have reviewed this change and it seems sane”.
The typical patch flow in the Git project is that contributors generate signed-off patches with git format-patch -s and send them to the project mailing list where they gather discussion and Acks (if necessary). Once the patch is ready to be applied, the maintainer applies it after adding his own “Signed-off-by:”. So, the maintainer is always the Committer (except in some subsystems where commits are pulled in with merges from the subsystem maintainers) but the original contributors are still the Author. This workflow may or may not make sense in other projects.
So, the “Signed-off-by:” in your example commit at GitHub is just text at the end of the commit message. Its exact meaning is whatever meaning the project has assigned to such lines. The additional identity shown for that commit (labeled as “(committer)” in the GitHub view) is due to the Committer being different from the Author. This happens when you amend a commit (e.g. the tip of a branch or during a rebase) or apply a patch that includes a “From:” header that is different from your configured identity. Amending someone else's commit to add a sign-off or ack line (or fix a typo in the commit message) will be enough to change the Committer.
In general, you should not be concerned with pushing your identity into the Committer field. You may reasonably be concerned with acknowledging the change embodied in a commit in some way though (e.g. to say “I reviewed this”, or “I approved this”). The way you do this depends on the customs and policies of the project in question. Often such acknowledgements are done by adding ‘footer’ lines to the commit message.
Ways to Add Acks
If “Signed-off-by:” lines server as Acks in your project, you can easily add them by amending commits with git commit --amend -s. Otherwise it will involve amending the commit message to include whatever signifier is appropriate for your project.
Completely Preserving Contributed History
If preserving the contributor's original history is vital in your situation, then you should probably use git pull --no-ff and add your “Ack” to the commit message of the resulting merge commit. Since you cannot rewrite, you will have to live with any commit message typos. For content typos, you or the original contributer can add a commit that fixes the typo either before the merge or you can add the fix-up after the merge.
With content fix-up after merge:
git checkout <your-branch>
git pull --no-ff --no-commit <repo> <contributor's-branch>
git commit # add your "Ack", commit the merge
# fix content typo and stage it
git commit
Completely Preserving Contributed History (with some extra changes on top)
With content fix-up before merge (or get the contributer to do it in his repository then pull as above, skipping the final fix-up step):
git fetch <repo> <contributor's-branch>:from-contributor
git checkout from-contributor
# fix content typo and stage it
git commit
git checkout <your-branch>
git merge --no-ff --no-commit from-contributor
git commit # add your Ack, commit the merge
You will be the Author and Committer of the merge commit and any fix-up commits. The Author and Comitter from the contributor's commits will be unchanged.
Rewriting Some Contributed History (but preserving the original branch point)
If it is okay to rewrite history then you could make a local branch that contains your contributor's commits, use git rebase -i to add your “Ack” and fix the typo, then merge that into your main branch.
git fetch <repo> <contributor's-branch>:from-contributor
git checkout from-contributor
git rebase -i HEAD~<N> # N is however many commits you have to go back to fix the typo
git checkout <your-branch>
git merge --no-ff --no-commit from-contributor
git commit # add your Ack, commit the merge
Instead of the final git checkout <your-branch> && git merge --no-ff --no-commit && git commit, you could add your ack to the relevant commits during the git rebase -i step then use git checkout <your-branch> && git merge from-contributor, which might make a fast-forward if the tip of <your-branch> is an ancestor of from-contributor.
You will be the Committer of any changed commits. The Author of existing commits will remain unchanged unless you use git commit --reset-author. You will be the Author and Committer of any new commits (the merge commit and and fixups).
Rewriting Any or All of the Contributed History
If you do not care to preserve the branch point of the contributor's branch then you may be able to do this instead:
git checkout <your-branch>
git pull --rebase <repo> <contributor's-branch>
git rebase -i HEAD~<N> # fix-up typo, add Ack
Author and Committer will be the same as the above rebase+merge scenario.
Acking/Fixing a Single Commit
If you are are just dealing with a single commit, the git rebase -i HEAD~<N> steps above can just be git commit --amend instead.