+pawel who I believe made a change regarding "git reset --hard HEAD" recently

Pawel: can you respond to #1?

Nevermind #2, this is not related to 'git reset --hard HEAD', it's the cleaning at https://cs.chromium.org/chromium/tools/depot_tools/gclient_scm.py?rcl=83051152f32458b829cd787dac37d03ce938d542&l=698 as mentioned in the bug description.

I've found a reasonable workaround for this though: I'll just create CLs for a few .gitignore files in src/third_party and src/build. They're needed when using these dirs as separate Git repos (but not in Chrome, since the top-level .gitignore covers the stuff that gets deleted here).

Doing that shouldn't affect Chromium: they'll just overlap with already existing entries in https://cs.chromium.org/chromium/src/.gitignore but nothing will break if the ones I'm adding is getting out of sync. It'll be in WebRTC and libyuv's interest to keep them at least somewhat up to date.

I posted https://codereview.chromium.org/2710593005/ in which I realized it's probably better to just move the entries out of the top-level .gitignore instead to avoid them getting out of sync. There are already 51 other .gitignore files in the src/ repo so adding 2 more won't make any difference.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/68d02518d39937443244001624fa500e00aad408

commit 68d02518d39937443244001624fa500e00aad408
Author: kjellander <kjellander@chromium.org>
Date: Wed Feb 22 19:52:16 2017

Add .gitignore files in build/ and third_party/

Having this, a lot of wasted bandwidth is avoided for projects
that use these directories as DEPS entries, since the top-level
Chromium .gitignore doesn't exist in those cases.

The src/ repo already contained 51 other .gitignore files anyway,
so it's hard to claim the top-level file has to be the only one.

BUG= 690010 

Review-Url: https://codereview.chromium.org/2710593005
Cr-Commit-Position: refs/heads/master@{#452167}

[modify] https://crrev.com/68d02518d39937443244001624fa500e00aad408/.gitignore
[add] https://crrev.com/68d02518d39937443244001624fa500e00aad408/build/.gitignore
[add] https://crrev.com/68d02518d39937443244001624fa500e00aad408/third_party/.gitignore

So... my .gitignore CL above was a little late to the party since https://chromium-review.googlesource.com/c/444308/ landed 5 days ago and took over the cleaning of these things. Now all these directories are wiped with a "Deleting residual after reset" message instead (example: [1]).

Adding the .gitignore files in build/ and third_party/ doesn't affect that cleaning, but I guess it would have solved this problem otherwise.

Robbie: could you help us on this? It has significant effect on our sync times, and it's loading Chrome infra unnecessary.

[1]: https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Fclient.webrtc%2FLinux64_Debug%2F11850%2F%2B%2Frecipes%2Fsteps%2Fbot_update%2F0%2Fstdout

Actually, I mistakenly assumed we had rolled in the .gitignore files, but we haven't yet rolled in #452167. The latest roll CL was doing 452017:452148 in https://codereview.webrtc.org/2712753002/

So let's wait a few hours and and see, maybe it actually fixes it!

Now that the .gitignore files are rolled in I can verify that they didn't have any effect.
The "Deleting residual after reset" functionality [1] is wiping these directories now. 

Robbie: Is there any way we could avoid this for projects using build/third_party Git subtree mirrors? I imagine we could avoid passing --delete_unversioned_trees, but that sounds a bit risky for other scenarios like when deps are added/removed etc, right? 

[1]: https://cs.chromium.org/chromium/tools/depot_tools/gclient_scm.py?rcl=53b8550acf5130d033253bc2743be99c12c51f02&l=314

So, it appears that this magically has resolved itself or was I verifying this in the wrong way. It actually DID solve the problem and now there are just a few entries that are wiped (mostly *.pyc files), so this is no longer an issue! Yay!