Added git hyper-blame, a tool that skips unwanted commits in git blame.

man/src/git-hyper-blame.txt

Index: man/src/git-hyper-blame.txt
diff --git a/man/src/git-hyper-blame.txt b/man/src/git-hyper-blame.txt
new file mode 100644
index 0000000000000000000000000000000000000000..8943c3935b7e9d288d0d0c70abe0cd265705ff36
--- /dev/null
+++ b/man/src/git-hyper-blame.txt
@@ -0,0 +1,72 @@
+git-hyper-blame(1)
+==================
+
+NAME
+----
+git-hyper-blame -
+include::_git-hyper-blame_desc.helper.txt[]
+
+SYNOPSIS
+--------
+[verse]
+'git hyper-blame' [-i <rev> [-i <rev> ...]] [<rev>] [--] <file>
+
+DESCRIPTION
+-----------
+
+`git hyper-blame` is like `git blame` but it can ignore or "look through" a
+given set of commits, to find the real culprit.
+
+This is useful if you have a commit that makes sweeping changes that are
+unlikely to be what you are looking for in a blame, such as mass reformatting or
+renaming. By adding these commits to the hyper-blame ignore list, `git
+hyper-blame` will look past these commits to find the previous commit that
+touched a given line.
+
+Follows the normal `blame` syntax: annotates `<file>` with the revision that
+last modified each line. Optional `<rev>` specifies the revision of `<file>` to
+start from.

[iannucci, 2016/01/29 19:29:25]

You know, it would be useful if we could use a git-notes ref on the origin repo
to mark certain commits as skippable by default so that folks don't have to
accumulate a list of to-be-skipped revisions.

[Matt Giuca, 2016/02/01 03:51:06]

See below.

+
+OPTIONS
+-------
+
+-i <rev>::
+  A revision to ignore. Can be specified as many times as needed.
+
+EXAMPLE
+-------
+
+Let's run `git blame` on a file:
+
+demo:1[]
+
+Notice that almost the entire file has been blamed on a formatting change? You
+aren't interested in the uppercasing of the file. You want to know who
+wrote/modified those lines in the first place. Just tell `hyper-blame` to ignore
+that commit:
+
+demo:2[]
+
+`hyper-blame` places a `*` next to any line where it has skipped over an ignored
+commit, so you know that the line in question has been changed (by an ignored
+commit) since the given person wrote it.
+
+BUGS
+----
+
+- When a commit is ignored, hyper-blame currently just blames the same line in
+  the previous version of the file. This can be wildly inaccurate if the ignored
+  commit adds or removes lines, resulting in a completely wrong commit being
+  blamed.
+- There is currently no way to pass the ignore list as a file.
+- It should be possible for a git repository to configure an automatic list of
+  commits to ignore (like `.gitignore`), so that project owners can maintain a
+  list of "big change" commits that are ignored by hyper-blame by default.

[iannucci, 2016/01/29 19:29:25]

er, right :)

I would definitely use git-notes though. Otherwise you have to double-commit.

[Matt Giuca, 2016/02/01 03:51:06]

If you can crack the SHA-1 algorithm then you should be able to land a single
commit that refers to itself in a file :)

Jokes aside, I'll have a look at git notes. My initial thoughts are that it
seems a bit anti-git to have an object that's conceptually part of the checkout
that isn't actually in version control, or rather it's in some kind of parallel
version control that isn't in lock-step with the main codebase. Even though a
hyper-blame ignore list is not a "core" part of a Chrome checkout, it would
still be nice if it was versioned properly.

I don't think the double-commit is a big problem, given that we shouldn't be
adding commits to the ignore list very often.

But in any case, that should not block this CL since we would definitely want to
implement the ignore list in a future CL.

+
+SEE ALSO
+--------
+linkgit:git-blame[1]
+
+include::_footer.txt[]
+
+// vim: ft=asciidoc: