git hyper-blame: Added automatically ignoring revs from a file.

git hyper-blame: Added automatically ignoring revs from a file.

Added --ignore-file argument, so you can specify ignored commits in a
file rather than as raw command-line arguments. Also, automatically
searches for a file called .git-blame-ignore-revs, which is
automatically used as an ignore list by default.

Also, specifying an unknown revision (either on the command line or in a
file) now generates a warning, not an error.

Notes on some decisions:
- The file is called .git-blame-ignore-revs (not mentioning hyper-blame)
  because we may use the same list in tools other than hyper-blame in
  the future.
- We look at the *currently checked out* version of
  .git-blame-ignore-revs (not the version at the specified revision) for
  consistency with .git-ignore. Because we only expect revisions to be
  added (not deleted), it should be fine to use an ignore list from a
  newer version than the revision being blamed.
- We considered using git notes for the ignore list so that you could
  add a revision to the ignore list without needing a follow-up CL.
  However, there are some problems with this approach. git notes is not
  automatically synced with git clone/pull. Also the Chromium infra
  tools (Reitveld, CQ) are not set up to allow modification of git
  notes, nor are changes to git notes subject to OWNERS checks. Using a
  regular file ensures all users synced to a particular revision are
  using the same ignore list.

BUG=574290
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=298897

[Matt Giuca, 2016-02-17 04:28:49]

Description was changed from

==========
git hyper-blame: Added automatically ignoring revs from a file.

Added --ignore-file argument, so you can specify ignored commits in a
file rather than as raw command-line arguments. Also, automatically
searches for a file called .git-blame-ignore-revs, which is
automatically used as an ignore list by default.

Also, specifying an unknown revision (either on the command line or in a
file) now generates a warning, not an error.

BUG=574290
==========

to

==========
git hyper-blame: Added automatically ignoring revs from a file.

Added --ignore-file argument, so you can specify ignored commits in a
file rather than as raw command-line arguments. Also, automatically
searches for a file called .git-blame-ignore-revs, which is
automatically used as an ignore list by default.

Also, specifying an unknown revision (either on the command line or in a
file) now generates a warning, not an error.

Notes on some decisions:
- The file is called .git-blame-ignore-revs (not mentioning hyper-blame)
  because we may use the same list in tools other than hyper-blame in
  the future.
- We look at the *currently checked out* version of
  .git-blame-ignore-revs (not the version at the specified revision) for
  consistency with .git-ignore. Because we only expect revisions to be
  added (not deleted), it should be fine to use an ignore list from a
  newer version than the revision being blamed.
- We considered using git notes for the ignore list so that you could
  add a revision to the ignore list without needing a follow-up CL.
  However, there are some problems with this approach. git notes is not
  automatically synced with git clone/pull. Also the Chromium infra
  tools (Reitveld, CQ) are not set up to allow modification of git
  notes, nor are changes to git notes subject to OWNERS checks. Using a
  regular file ensures all users synced to a particular revision are
  using the same ignore list.

BUG=574290
==========

[Matt Giuca, 2016-02-17 04:31:07]

mgiuca@chromium.org changed reviewers:
+ iannucci@chromium.org, thakis@chromium.org

[Matt Giuca, 2016-02-17 04:31:07]

iannucci: For code review.
thakis: For policy (how exactly should we specify the default file?).

I had some justification for some of the decisions I made which I put into the
CL description for posterity. Let me know if you disagree with any of those
decisions. In particular, Robert suggested using git notes [1], but I
investigated it and found a number of issues.

Parallel code review for the initial version of .git-blame-ignore-revs in
Chromium:
https://codereview.chromium.org/1705503004

[1]
https://chromiumcodereview.appspot.com/1559943003/diff/230001/man/src/git-hyp...

[Matt Giuca, 2016-02-17 04:31:45]

Description was changed from

==========
git hyper-blame: Added automatically ignoring revs from a file.

Added --ignore-file argument, so you can specify ignored commits in a
file rather than as raw command-line arguments. Also, automatically
searches for a file called .git-blame-ignore-revs, which is
automatically used as an ignore list by default.

Also, specifying an unknown revision (either on the command line or in a
file) now generates a warning, not an error.

Notes on some decisions:
- The file is called .git-blame-ignore-revs (not mentioning hyper-blame)
  because we may use the same list in tools other than hyper-blame in
  the future.
- We look at the *currently checked out* version of
  .git-blame-ignore-revs (not the version at the specified revision) for
  consistency with .git-ignore. Because we only expect revisions to be
  added (not deleted), it should be fine to use an ignore list from a
  newer version than the revision being blamed.
- We considered using git notes for the ignore list so that you could
  add a revision to the ignore list without needing a follow-up CL.
  However, there are some problems with this approach. git notes is not
  automatically synced with git clone/pull. Also the Chromium infra
  tools (Reitveld, CQ) are not set up to allow modification of git
  notes, nor are changes to git notes subject to OWNERS checks. Using a
  regular file ensures all users synced to a particular revision are
  using the same ignore list.

BUG=574290
==========

to

==========
git hyper-blame: Added automatically ignoring revs from a file.

Added --ignore-file argument, so you can specify ignored commits in a
file rather than as raw command-line arguments. Also, automatically
searches for a file called .git-blame-ignore-revs, which is
automatically used as an ignore list by default.

Also, specifying an unknown revision (either on the command line or in a
file) now generates a warning, not an error.

Notes on some decisions:
- The file is called .git-blame-ignore-revs (not mentioning hyper-blame)
  because we may use the same list in tools other than hyper-blame in
  the future.
- We look at the *currently checked out* version of
  .git-blame-ignore-revs (not the version at the specified revision) for
  consistency with .git-ignore. Because we only expect revisions to be
  added (not deleted), it should be fine to use an ignore list from a
  newer version than the revision being blamed.
- We considered using git notes for the ignore list so that you could
  add a revision to the ignore list without needing a follow-up CL.
  However, there are some problems with this approach. git notes is not
  automatically synced with git clone/pull. Also the Chromium infra
  tools (Reitveld, CQ) are not set up to allow modification of git
  notes, nor are changes to git notes subject to OWNERS checks. Using a
  regular file ensures all users synced to a particular revision are
  using the same ignore list.

BUG=574290
==========

[Nico, 2016-02-17 20:22:13]

Using a check-ed in dot file for this sounds great to me. I think that's a lot
less magical for most devs than `git notes`.

[iannucci, 2016-02-18 01:16:14]

lgtm. 

The only reason I brought up notes is because the assumption of
refs/heads/master@HEAD I think may cause issues (e.g. when running from a
release branch or something like that), but I don't mind.

[Matt Giuca, 2016-02-18 04:26:06]

On 2016/02/18 01:16:14, iannucci wrote:
> lgtm. 
> 
> The only reason I brought up notes is because the assumption of
> refs/heads/master@HEAD I think may cause issues (e.g. when running from a
> release branch or something like that), but I don't mind.

I don't know what ref/heads/master@HEAD has to do with it. I don't hard-code
anything like that. In this implementation, I just look for files called
.git-blame-ignore-revs in the current working tree. If you have a release branch
checked out, it'll use the .git-blame-ignore-revs as it was during the release
branch (which means it might not be up to date if you are in a release branch
and run hyper-blame on a commit from master). The solution to that is to look
for .git-blame-ignore-revs in the repo tree corresponding to the blamed revision
(don't need git notes). But I didn't do that for consistency with .gitignore.
And it is a pretty rare corner case.

[Matt Giuca, 2016-02-19 04:09:00]

Patchset #2 (id:20001) has been deleted

[Matt Giuca, 2016-02-19 04:09:31]

iannucci: PTAL (as you suggested on the other CL, made it so
.git-blame-ignore-revs is only located in the top-level directory).

[iannucci, 2016-02-19 04:34:32]

lgtm

[iannucci, 2016-02-19 04:34:47]

may want to update the cl description too

[Matt Giuca, 2016-02-22 00:23:34]

On 2016/02/19 04:34:47, iannucci wrote:
> may want to update the cl description too

I can't find anything in the existing CL description that is no longer true...?

[Matt Giuca, 2016-02-22 00:24:03]

The CQ bit was checked by mgiuca@chromium.org

[commit-bot: I haz the power, 2016-02-22 00:24:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1697423004/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1697423004/40001

[commit-bot: I haz the power, 2016-02-22 00:28:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-22 00:28:07]

Try jobs failed on following builders:
  depot_tools_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/depot_tools_pre...)

[Matt Giuca, 2016-02-22 00:38:36]

The CQ bit was checked by mgiuca@chromium.org

[Matt Giuca, 2016-02-22 00:38:36]

The patchset sent to the CQ was uploaded after l-g-t-m from
iannucci@chromium.org
Link to the patchset: https://codereview.chromium.org/1697423004/#ps60001
(title: "Avoid too-long line.")

[commit-bot: I haz the power, 2016-02-22 00:38:38]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1697423004/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1697423004/60001

[commit-bot: I haz the power, 2016-02-22 00:40:34]

Description was changed from

==========
git hyper-blame: Added automatically ignoring revs from a file.

Added --ignore-file argument, so you can specify ignored commits in a
file rather than as raw command-line arguments. Also, automatically
searches for a file called .git-blame-ignore-revs, which is
automatically used as an ignore list by default.

Also, specifying an unknown revision (either on the command line or in a
file) now generates a warning, not an error.

Notes on some decisions:
- The file is called .git-blame-ignore-revs (not mentioning hyper-blame)
  because we may use the same list in tools other than hyper-blame in
  the future.
- We look at the *currently checked out* version of
  .git-blame-ignore-revs (not the version at the specified revision) for
  consistency with .git-ignore. Because we only expect revisions to be
  added (not deleted), it should be fine to use an ignore list from a
  newer version than the revision being blamed.
- We considered using git notes for the ignore list so that you could
  add a revision to the ignore list without needing a follow-up CL.
  However, there are some problems with this approach. git notes is not
  automatically synced with git clone/pull. Also the Chromium infra
  tools (Reitveld, CQ) are not set up to allow modification of git
  notes, nor are changes to git notes subject to OWNERS checks. Using a
  regular file ensures all users synced to a particular revision are
  using the same ignore list.

BUG=574290
==========

to

==========
git hyper-blame: Added automatically ignoring revs from a file.

Added --ignore-file argument, so you can specify ignored commits in a
file rather than as raw command-line arguments. Also, automatically
searches for a file called .git-blame-ignore-revs, which is
automatically used as an ignore list by default.

Also, specifying an unknown revision (either on the command line or in a
file) now generates a warning, not an error.

Notes on some decisions:
- The file is called .git-blame-ignore-revs (not mentioning hyper-blame)
  because we may use the same list in tools other than hyper-blame in
  the future.
- We look at the *currently checked out* version of
  .git-blame-ignore-revs (not the version at the specified revision) for
  consistency with .git-ignore. Because we only expect revisions to be
  added (not deleted), it should be fine to use an ignore list from a
  newer version than the revision being blamed.
- We considered using git notes for the ignore list so that you could
  add a revision to the ignore list without needing a follow-up CL.
  However, there are some problems with this approach. git notes is not
  automatically synced with git clone/pull. Also the Chromium infra
  tools (Reitveld, CQ) are not set up to allow modification of git
  notes, nor are changes to git notes subject to OWNERS checks. Using a
  regular file ensures all users synced to a particular revision are
  using the same ignore list.

BUG=574290

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=298897
==========

[commit-bot: I haz the power, 2016-02-22 00:40:34]

Committed patchset #3 (id:60001) as
http://src.chromium.org/viewvc/chrome?view=rev&revision=298897