Skip to content

C
Chromium_Depot_tools
Switch branch/tag
  1. 06 May, 2019 1 commit
  3. 03 May, 2019 1 commit
  5. 02 May, 2019 1 commit
    • Bruce Dawson's avatar
      Fix multiple confusingly escaped regex strings · 9c062012
      Bruce Dawson authored 
      Python (prior to 3.8) treats meaningless string escape sequences as if
they were a slash followed by the character. That is, '\w' == '\\w'.
Python 3.8 rejects this, and it's confusing. This change fixes seven of these
regex strings found in depot_tools (through a regex search, natch). Most of
the fixes don't actually change the value of the strings, and this was
manually verified:

>>> '(/c(/.*/\+)?)?/(\d+)(/(\d+)?/?)?$' == r'(/c(/.*/\+)?)?/(\d+)(/(\d+)?/?)?$'
True
>>> '#\s*OWNERS_STATUS\s+=\s+(.+)$' == r'#\s*OWNERS_STATUS\s+=\s+(.+)$'
True
>>> 'COM\d' == r'COM\d'
True
>>> '^\s+Change-Id:\s*(\S+)$' == r'^\s+Change-Id:\s*(\S+)$'
True
>>> 'ETag:\s+([a-z0-9]{32})' == r'ETag:\s+([a-z0-9]{32})'
True

Two exceptions were the regex expressions in filter_demo_output.py and scm.py.
These were turned into raw strings despite this changing the value of the
string passed to re. This works because re supports the \x, \d, \w, \t, and
other escape sequences needed to make this work.

TL;DR - use raw strings for regex to avoid melting your brain. If bulk changing
regex strings to raw watch out for double-slashes.

Bug: 958138
Change-Id: Ic45264cfc63e8bae9cfcffe2cd88a57c2d3dcdae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1590534
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: 's avatarDirk Pranke <dpranke@chromium.org>
      9c062012
  7. 13 Dec, 2018 2 commits
  9. 05 Dec, 2018 1 commit
    • Clemens Hammacher's avatar
      Revert "Fix semantics of git new-branch --upstream" · 19238fc3
      Clemens Hammacher authored 
      This reverts commit ba83229a.

Reason for revert: After mail discussion we came to the conclusion that the old behavior makes more sense.

Original change's description:
> Fix semantics of git new-branch --upstream
> 
> Currently, the "--upstream A" option for new-branch behaves totally
> different than "--upstream_current". While "--upstream A" checks out
> branch A and then creates a new branch which tracks A,
> "--upstream_current" creates a new branch for the current HEAD and sets
> the upstream to the previously checked out branch.
> 
> As the documentation does not mention that any of the options changes
> the currently-checked-out commit (HEAD), this CL changes the semantics
> of "git new-branch --upstream A B" to be identical to "git checkout -b B
> && git branch --set-upstream-to A".
> 
> It also slightly extends the documentation to mention that in any case
> the new branch is based on HEAD.
> 
> R=​iannucci@chromium.org
> 
> Change-Id: Ic335d2caf27cb6afca1b8bc5a008424c0e880fca
> Reviewed-on: https://chromium-review.googlesource.com/c/1350748
> Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Auto-Submit: Clemens Hammacher <clemensh@chromium.org>

TBR=iannucci@chromium.org,tandrii@chromium.org,clemensh@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Change-Id: I7463935af172f0801c7da94d2de106a02fc4c42e
Reviewed-on: https://chromium-review.googlesource.com/c/1362972Reviewed-by: 's avatarSergiy Belozorov <sergiyb@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      19238fc3
  11. 04 Dec, 2018 1 commit
    • Clemens Hammacher's avatar
      Fix semantics of git new-branch --upstream · ba83229a
      Clemens Hammacher authored 
      Currently, the "--upstream A" option for new-branch behaves totally
different than "--upstream_current". While "--upstream A" checks out
branch A and then creates a new branch which tracks A,
"--upstream_current" creates a new branch for the current HEAD and sets
the upstream to the previously checked out branch.

As the documentation does not mention that any of the options changes
the currently-checked-out commit (HEAD), this CL changes the semantics
of "git new-branch --upstream A B" to be identical to "git checkout -b B
&& git branch --set-upstream-to A".

It also slightly extends the documentation to mention that in any case
the new branch is based on HEAD.

R=iannucci@chromium.org

Change-Id: Ic335d2caf27cb6afca1b8bc5a008424c0e880fca
Reviewed-on: https://chromium-review.googlesource.com/c/1350748Reviewed-by: 's avatarRobbie Iannucci <iannucci@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Auto-Submit: Clemens Hammacher <clemensh@chromium.org>
      ba83229a
  13. 03 Dec, 2018 1 commit
  15. 21 Jun, 2018 1 commit
  17. 24 May, 2018 1 commit
  19. 06 Apr, 2018 1 commit
  21. 03 Nov, 2017 1 commit
  23. 21 Jun, 2017 1 commit
  25. 31 May, 2017 1 commit
  27. 13 Mar, 2017 1 commit
  29. 24 Jan, 2017 1 commit
  31. 16 Dec, 2016 2 commits
  33. 29 Sep, 2016 2 commits
  35. 22 Sep, 2016 1 commit
  37. 04 Sep, 2016 1 commit
  39. 22 Jul, 2016 1 commit
  41. 21 Jul, 2016 1 commit
  43. 20 Jul, 2016 1 commit
  45. 22 Jun, 2016 1 commit
  47. 01 Apr, 2016 1 commit
  49. 22 Feb, 2016 1 commit
    • mgiuca@chromium.org's avatar
      git hyper-blame: Added automatically ignoring revs from a file. · cd0a1cf3
      mgiuca@chromium.org authored 
      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

Review URL: https://codereview.chromium.org/1697423004

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298897 0039d316-1c4b-4281-b951-d872f2087c98
      cd0a1cf3
  51. 05 Feb, 2016 1 commit
  53. 03 Feb, 2016 1 commit
  55. 03 Nov, 2015 1 commit
  57. 29 Sep, 2015 1 commit
  59. 10 Sep, 2015 1 commit
  61. 13 Jan, 2015 1 commit
  63. 16 Dec, 2014 1 commit
  65. 15 Dec, 2014 1 commit
  67. 01 Oct, 2014 1 commit
  69. 23 Sep, 2014 1 commit
  71. 09 Sep, 2014 2 commits