Google Git
Sign in
chromium / chromiumos / platform / redaction_tool / refs/heads/factory-skyrim-15384.B
commit649e9a45c023170ed76b2f7a94cef4fd654cc0d8[log] [tgz]
authorDonna Dionne <donnadionne@chromium.org>Sat Mar 04 00:13:32 2023
committerChromeos LUCI <chromeos-scoped@luci-project-accounts.iam.gserviceaccount.com>Tue Mar 07 01:56:31 2023
tree4fa2d11ba3f3636d2cf7a6ab3908293c03c2075e
parent174dfcd0563ce97925be85006fce0f060d8f08b4 [diff]
redaction_tool: Keeping the source up-to-date

UMA metrics were added to redaction tool; uprev to keep the source
up-to-date.

BUG=b:265030885
TEST=unit tests

Change-Id: Ifb1fadc875ca7f466005bcb015384bcf3072d602
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/redaction_tool/+/4308014
Tested-by: Ramya Gopalan <ramyagopalan@google.com>
Tested-by: Nik K <nikj@chromium.org>
Reviewed-by: Nik K <nikj@chromium.org>
Reviewed-by: Donna Dionne <donnadionne@chromium.org>
Commit-Queue: Donna Dionne <donnadionne@chromium.org>
Reviewed-by: Ramya Gopalan <ramyagopalan@google.com>
2 files changed
tree: 4fa2d11ba3f3636d2cf7a6ab3908293c03c2075e
  1. BUILD.gn
  2. DIR_METADATA
  3. ip_address.cc
  4. ip_address.h
  5. OWNERS
  6. pii_types.h
  7. README.md
  8. redaction_tool.cc
  9. redaction_tool.h
  10. redaction_tool_unittest.cc
  11. url_canon.h
  12. url_canon_internal.cc
  13. url_canon_internal.h
  14. url_canon_ip.cc
  15. url_canon_ip.h
  16. url_canon_stdstring.cc
  17. url_canon_stdstring.h
  18. url_parse.h
README.md

redaction_tool: PII Redaction Tool

A redaction_tool redacts PII using a wide set of RegEx expressions.

This code is a mirror of https://source.chromium.org/chromium/chromium/src/+/main:components/feedback/redaction_tool/

Changes should be made in chromium code base only and then be upreved here.

How to update the source

To pull in updates from chromium/src, do the following:

  • git remote update
  • git checkout -b main cros/main
  • git merge cros/upstream/main
    • BUILD.gn should mostly use the version from main, unless the upstream changes the files to be built.
    • The #include paths should use the version from main (without “components/feedback”). This should be the majority of the merge conflicts.
    • In the commit message of the merge, list the commits from upstream that are merged.
    • If you need to make changes to the merged commits (outside of conflicts), do that work in separate commits. For example, if you need to revert commits, use git revert after committing the merge commit. This preserves the history and makes it clear why a change is being reverted rather than quietly changing it in the merge commit.
    • Check the changes introduced by your merge by doing a diff against the commit before the merge. The difference should be the same as the changes in the upstream.
  • Push the resulting merge commit for review with:
    • git push HEAD:refs/for/main