Added .git-blame-ignore-revs.

Added .git-blame-ignore-revs.

This file will be used to record revisions to be ignored by default by
git hyper-blame. For now, it just contains comments outlining some
guidelines on how to append new revisions to the file. It has no actual
revisions.

BUG=574290
Committed: https://crrev.com/844fee69d193b942146fc2502dad41e7effdbb0c
Cr-Commit-Position: refs/heads/master@{#376868}

[Matt Giuca, 2016-02-17 04:36:15]

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

[Matt Giuca, 2016-02-17 04:36:16]

Parallel CL to the depot_tools change to add support for .git-blame-ignore-revs.
(Will wait for complete review on both CLs before landing, to give us
opportunity to change the name of this file, syntax, etc.)

See https://codereview.chromium.org/1697423004/ for justification of this
format.

See Patch Set 1 for an example of how this might be used.

Some issues here:
- Do we want a single top-level .git-blame-ignore-revs file, or should we place
them in more granular directories (e.g., have one for third_party/WebKit)? I
elected to just have one so we can see at a glance what all of the ignored
commits are. We can split it up later if necessary. hyper-blame looks for this
file in every directory, like .gitignore.
- Should there be a special OWNERS rule for who can modify this file? We need to
be responsible and only add legitimately "unimportant" CLs to this list.

I'll get a top-level owner to review once we sort out these questions.

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

lgtm!

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

mgiuca@chromium.org changed reviewers:
+ brettw@chromium.org

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

+brettw for top-level OWNERS.

[Nico, 2016-02-18 14:28:54]

this morning's shower thought: since we're only going to use this for blink for
now, should this file live in third_party/WebKit/Source for now?

[Matt Giuca, 2016-02-18 23:48:36]

On 2016/02/18 14:28:54, Nico wrote:
> this morning's shower thought: since we're only going to use this for blink
for
> now, should this file live in third_party/WebKit/Source for now?

That's a possibility (I raised in the mailout for this CL). I decided to put it
at the top level because I think this is generally useful; we can do big
cleanups in Chromium too, and add them here. And I'm guessing third_party/WebKit
won't exist forever.

But that doesn't really matter, because we can always move this later. Happy to
put it in third_party/WebKit/Source if you want it there.

[Nico, 2016-02-18 23:50:12]

I don't feel strongly. I feel weakly that we probably won't need it at the
toplevel soon, so I wouldn't put it there yet, but doesn't matter too much
either way :-)

[iannucci1, 2016-02-18 23:56:29]

On 2016/02/18 23:50:12, Nico wrote:
> I don't feel strongly. I feel weakly that we probably won't need it at the
> toplevel soon, so I wouldn't put it there yet, but doesn't matter too much
> either way :-)

I would weakly suggest that it makes sense to have it at toplevel, because the
commits that it contains are whole-repo commits, and hyper-blame works at the
commit level and not the subdir level (IIUC). If it's in a subdir, then you have
to think about lookup and chaining rules (bleh). If you blame a file outside of
webkit/source (like looking at an #include line or something), would you expect
it to take effect, or not?

[Matt Giuca, 2016-02-19 00:14:35]

On 2016/02/18 23:56:29, iannucci1 wrote:
> On 2016/02/18 23:50:12, Nico wrote:
> > I don't feel strongly. I feel weakly that we probably won't need it at the
> > toplevel soon, so I wouldn't put it there yet, but doesn't matter too much
> > either way :-)
> 
> I would weakly suggest that it makes sense to have it at toplevel, because the
> commits that it contains are whole-repo commits, and hyper-blame works at the
> commit level and not the subdir level (IIUC). If it's in a subdir, then you
have
> to think about lookup and chaining rules (bleh).

hyper-blame will look at any .git-blame-ignore-revs file that is a sibling of
the file being blamed (where it is *now*, not considering where it has been in
the past), and any ancestor directories of that, up to the repo root. So if we
put it in third_party/WebKit/Source or third_party/WebKit, it will work only on
files inside WebKit, and if we move those files later, it will continue to work
as long as we move .git-blame-ignore-revs too.

But yes, conceptually I think it belongs at the top level, because it does refer
to commits, not files. Arguably, hyper-blame should only look at the top level
and not a subdir. It doesn't make a lot of sense that you can ignore a
particular commit but only for files within a certain directory, while that
commit can still show up in blame for files in other directories.

> If you blame a file outside of
> webkit/source (like looking at an #include line or something), would you
expect
> it to take effect, or not?

Currently, it would not take effect. So I am more convinced now to put it at the
top level, and possibly (do you think?) remove the subdir lookup logic in
https://codereview.chromium.org/1697423004/ (which has not landed yet).

[iannucci1, 2016-02-19 00:20:59]

On 2016/02/19 00:14:35, Matt Giuca wrote:
> On 2016/02/18 23:56:29, iannucci1 wrote:
> > On 2016/02/18 23:50:12, Nico wrote:
> > > I don't feel strongly. I feel weakly that we probably won't need it at the
> > > toplevel soon, so I wouldn't put it there yet, but doesn't matter too much
> > > either way :-)
> > 
> > I would weakly suggest that it makes sense to have it at toplevel, because
the
> > commits that it contains are whole-repo commits, and hyper-blame works at
the
> > commit level and not the subdir level (IIUC). If it's in a subdir, then you
> have
> > to think about lookup and chaining rules (bleh).
> 
> hyper-blame will look at any .git-blame-ignore-revs file that is a sibling of
> the file being blamed (where it is *now*, not considering where it has been in
> the past), and any ancestor directories of that, up to the repo root. So if we
> put it in third_party/WebKit/Source or third_party/WebKit, it will work only
on
> files inside WebKit, and if we move those files later, it will continue to
work
> as long as we move .git-blame-ignore-revs too.
> 
> But yes, conceptually I think it belongs at the top level, because it does
refer
> to commits, not files. Arguably, hyper-blame should only look at the top level
> and not a subdir. It doesn't make a lot of sense that you can ignore a
> particular commit but only for files within a certain directory, while that
> commit can still show up in blame for files in other directories.
> 
> > If you blame a file outside of
> > webkit/source (like looking at an #include line or something), would you
> expect
> > it to take effect, or not?
> 
> Currently, it would not take effect. So I am more convinced now to put it at
the
> top level, and possibly (do you think?) remove the subdir lookup logic in
> https://codereview.chromium.org/1697423004/ (which has not landed yet).

IMO, I would keep the lookup logic as simple as possible: look at the toplevel
dir, and nothing else.

[Matt Giuca, 2016-02-19 00:31:46]

On 2016/02/19 00:20:59, iannucci1 wrote:
> On 2016/02/19 00:14:35, Matt Giuca wrote:
> > On 2016/02/18 23:56:29, iannucci1 wrote:
> > > On 2016/02/18 23:50:12, Nico wrote:
> > > > I don't feel strongly. I feel weakly that we probably won't need it at
the
> > > > toplevel soon, so I wouldn't put it there yet, but doesn't matter too
much
> > > > either way :-)
> > > 
> > > I would weakly suggest that it makes sense to have it at toplevel, because
> the
> > > commits that it contains are whole-repo commits, and hyper-blame works at
> the
> > > commit level and not the subdir level (IIUC). If it's in a subdir, then
you
> > have
> > > to think about lookup and chaining rules (bleh).
> > 
> > hyper-blame will look at any .git-blame-ignore-revs file that is a sibling
of
> > the file being blamed (where it is *now*, not considering where it has been
in
> > the past), and any ancestor directories of that, up to the repo root. So if
we
> > put it in third_party/WebKit/Source or third_party/WebKit, it will work only
> on
> > files inside WebKit, and if we move those files later, it will continue to
> work
> > as long as we move .git-blame-ignore-revs too.
> > 
> > But yes, conceptually I think it belongs at the top level, because it does
> refer
> > to commits, not files. Arguably, hyper-blame should only look at the top
level
> > and not a subdir. It doesn't make a lot of sense that you can ignore a
> > particular commit but only for files within a certain directory, while that
> > commit can still show up in blame for files in other directories.
> > 
> > > If you blame a file outside of
> > > webkit/source (like looking at an #include line or something), would you
> > expect
> > > it to take effect, or not?
> > 
> > Currently, it would not take effect. So I am more convinced now to put it at
> the
> > top level, and possibly (do you think?) remove the subdir lookup logic in
> > https://codereview.chromium.org/1697423004/ (which has not landed yet).
> 
> IMO, I would keep the lookup logic as simple as possible: look at the toplevel
> dir, and nothing else.

OK, I will do that.

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

brettw: PTAL

[brettw, 2016-02-22 23:09:45]

lgtm

[Matt Giuca, 2016-02-22 23:55:17]

The CQ bit was checked by mgiuca@chromium.org

[commit-bot: I haz the power, 2016-02-22 23:56:06]

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

[commit-bot: I haz the power, 2016-02-23 00:31:17]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-02-23 00:32:45]

Description was changed from

==========
Added .git-blame-ignore-revs.

This file will be used to record revisions to be ignored by default by
git hyper-blame. For now, it just contains comments outlining some
guidelines on how to append new revisions to the file. It has no actual
revisions.

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

to

==========
Added .git-blame-ignore-revs.

This file will be used to record revisions to be ignored by default by
git hyper-blame. For now, it just contains comments outlining some
guidelines on how to append new revisions to the file. It has no actual
revisions.

BUG=574290

Committed: https://crrev.com/844fee69d193b942146fc2502dad41e7effdbb0c
Cr-Commit-Position: refs/heads/master@{#376868}
==========

[commit-bot: I haz the power, 2016-02-23 00:32:46]

Patchset 2 (id:??) landed as
https://crrev.com/844fee69d193b942146fc2502dad41e7effdbb0c
Cr-Commit-Position: refs/heads/master@{#376868}