Skip to content

C
Chromium_Depot_tools
Switch branch/tag
  1. 02 Jul, 2021 1 commit
  3. 29 Jun, 2021 1 commit
  5. 01 Apr, 2021 1 commit
  7. 27 Jan, 2021 1 commit
  9. 13 Jan, 2021 1 commit
  11. 17 Sep, 2020 1 commit
  13. 16 Sep, 2020 1 commit
  15. 15 Sep, 2020 1 commit
  17. 11 Aug, 2020 1 commit
  19. 01 Apr, 2020 1 commit
  21. 31 Mar, 2020 1 commit
  23. 06 Dec, 2019 1 commit
  25. 11 Oct, 2019 1 commit
    • Marc-Antoine Ruel's avatar
      python3 improvements · 8e57b4bc
      Marc-Antoine Ruel authored 
      Ran:
  vi $(git grep --name-only iteritems | grep -v third_party)
  vi $(git grep --name-only itervalues | grep -v third_party)
  vi $(git grep --name-only 'print ' | grep -v third_party)

and edited the files quickly with adhoc macros. Then ran in recipes/:
  ./recipes.py test train

There was only a small subset of files that had been updated to use
six.iteritems() and six.itervalues(). Since the dataset size that is
being used in gclient is small (pretty much always below 200 items),
it's better to just switch to .items() right away and take the temporary
performance hit, so that we don't need to come back to rewrite the code.

Recipe-Nontrivial-Roll: build
Bug: 984182
Change-Id: I5faf11486b66b0d73c9098ab0f2ce1b15a45c53e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1854900
Commit-Queue: Edward Lesmes <ehmaldonado@chromium.org>
Reviewed-by: 's avatarEdward Lesmes <ehmaldonado@chromium.org>
Auto-Submit: Marc-Antoine Ruel <maruel@chromium.org>
      8e57b4bc
  27. 06 May, 2019 1 commit
  29. 03 May, 2019 1 commit
  31. 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
  33. 13 Dec, 2018 2 commits
  35. 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
  37. 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
  39. 03 Dec, 2018 1 commit
  41. 21 Jun, 2018 1 commit
  43. 24 May, 2018 1 commit
  45. 06 Apr, 2018 1 commit
  47. 03 Nov, 2017 1 commit
  49. 21 Jun, 2017 1 commit
  51. 31 May, 2017 1 commit
  53. 13 Mar, 2017 1 commit
  55. 24 Jan, 2017 1 commit
  57. 16 Dec, 2016 2 commits
  59. 29 Sep, 2016 2 commits
  61. 22 Sep, 2016 1 commit
  63. 04 Sep, 2016 1 commit
  65. 22 Jul, 2016 1 commit
  67. 21 Jul, 2016 1 commit
  69. 20 Jul, 2016 1 commit
  71. 22 Jun, 2016 1 commit
  73. 01 Apr, 2016 1 commit