The recent pylint 1.3.1 and 1.4.0 upgrades have caused some new errors
to be reported for presubmit_unittest:
* presubmit_support.InputApi.AffectedFiles() expectes a parameter called
|include_deletes|, not |include_deleted|.
* The mock AffectedFiles() implementation in
CannedChecksUnittest.testCannedCheckChangeHasNoTabs() had its
signature updated to match the one in presubmit_support.InputApi,
otherwise pylint would (erroneously) consider that this mock
implementation was used in all other AffectedFiles() invocations in
CannedChecksUnittest and complain that some parameters were missing.
It makes more sense to do this than disable the check and miss real
problems in the future.
R=maruel@chromium.org, iannucci@chromium.org, pgervais@chromium.org
BUG=443232
Review URL: https://codereview.chromium.org/802403003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293468 0039d316-1c4b-4281-b951-d872f2087c98
This is similar to r247914 and r149742: urllib does not work with SSL
connections behind proxies, we need to use urllib2 instead. Doing this
should allow people behind proxies to download gsutils 4.7 after
r293413.
(Setting NOTRY here to be able to land the issue, otherwise the CQ fails when running some presubmit checks, see crbug.com/443232)
R=maruel@chromium.org, hinoka@chromium.org, pgervais@chromium.org, primiano@chromium.org
NOTRY=true
Review URL: https://codereview.chromium.org/809053002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293439 0039d316-1c4b-4281-b951-d872f2087c98
The idea here is that when one of the filters are cleaned up in Chromium,
they should not be filtered out, otherwise we won't catch them in
the presubmit step.
See for example -> https://codereview.chromium.org/788493002/
BUG=None
R=agable@chromium.org, dpranke@chromium.org
Review URL: https://codereview.chromium.org/779033003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293357 0039d316-1c4b-4281-b951-d872f2087c98
Reason for revert:
The test intoruced is flake (see crrev.com/753543006/).
Need to look into that with more patience as it reproduces only on precise.
Original issue's description:
> Make gclient ready for the Blink (DEPS to main project) transition
>
> This CL makes gclient understand correctly whether a git project is
> being moved from DEPS to an upper project and vice-versa.
> The driving use case for this is the upcoming Blink merge, where
> third_party/Webkit will be removed from DEPS (and .gitignore) and will
> become part of the main project.
>
> At present state, gclient leaves the .git folder around when a project
> is removed from DEPS, and that causes many problems.
>
> Furthermore this CL solves the performance problem of bisecting across
> the merge point. The subproject's (Blink) .git/ folder is moved to a
> backup location (in the main checkout root) and is restored when moving
> backwards, avoiding a re-fetch when bisecting across the merge point.
>
> BUG=431469
>
> Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=293329
TBR=iannucci@chromium.org,maruel@chromium.org,jochen@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=431469
Review URL: https://codereview.chromium.org/796053002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293352 0039d316-1c4b-4281-b951-d872f2087c98
I ran into several failures running the presubmit checks
on my Ubuntu/Trusty laptop and it looks like a some of
the tests were broken by recent versions of svn and git.
Review URL: https://codereview.chromium.org/795723003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293341 0039d316-1c4b-4281-b951-d872f2087c98
This CL makes gclient understand correctly whether a git project is
being moved from DEPS to an upper project and vice-versa.
The driving use case for this is the upcoming Blink merge, where
third_party/Webkit will be removed from DEPS (and .gitignore) and will
become part of the main project.
At present state, gclient leaves the .git folder around when a project
is removed from DEPS, and that causes many problems.
Furthermore this CL solves the performance problem of bisecting across
the merge point. The subproject's (Blink) .git/ folder is moved to a
backup location (in the main checkout root) and is restored when moving
backwards, avoiding a re-fetch when bisecting across the merge point.
BUG=431469
Review URL: https://codereview.chromium.org/743083002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293329 0039d316-1c4b-4281-b951-d872f2087c98
This is for transitioning us out of the horribly outdated gsutil 3.4 thats
currently residing in depot_tools. This script:
1. Downloads GSUtil, pinned to a version (4.6 by default).
2. Executes GSUtil with the given parameters
3. (TODO) Runs the fallback GSUtil if #2 fails.
The transition plan is:
1. Set the fallback as default, making this script a no-op
2. Modify recipes (main consumer of gsutil) to pass in --force_version 4.6
3. Switch 4.6 as the default for gsutil.py
4. Make fallback failure a loud red failure
5. Remove depot_tools/third_party/gsutil
BUG=434422
Review URL: https://codereview.chromium.org/742173002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293320 0039d316-1c4b-4281-b951-d872f2087c98
This fix is created to avoid having to rebuild all the WebRTC
Git mirrors since they're configured to sync with the http URL
instead of https (resulting in git-svn-id Git footers with the
http URL in the commit messages). Without rewriting this, it is
not possible to commit to SVN since Google code disallows committing
to a http URL.
BUG=412012
TEST=Created a CL using a Git repo like this (both before and after landing https://webrtc-codereview.appspot.com/32569004):
git clone https://chromium.googlesource.com/external/webrtc.git
cd webrtc
git auto-svn
git checkout master
git checkout -b test
(edit whitespace change)
git commit -am "Whitespace edit
git cl upload --bypass-hooks"
git cl dcommit
R=agable@chromium.org, machenbach@chromium.org, mmoss@chromium.org
Review URL: https://codereview.chromium.org/760903004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293171 0039d316-1c4b-4281-b951-d872f2087c98
Reason for revert:
Makes `git cl upload` very slow in chrome checkouts.
Original issue's description:
> Added orphaned compiled Python file checks.
>
> There have been a handful of cases where orphaned compiled Python files (.pyc
> files without an accompanying .py file) have been loaded preferentially by
> the presubmit scripts, causing weird problems. This adds a check and a mode for
> such files, either warning the user or deleting them.
>
> BUG=None
> TEST=local
> - Tested against local repository.
>
> R=iannucci@chromium.org, szager@chromium.org
>
> Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=292703
TBR=iannucci@chromium.org,szager@chromium.org,dnj@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=None
Review URL: https://codereview.chromium.org/701683002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@292818 0039d316-1c4b-4281-b951-d872f2087c98
There have been a handful of cases where orphaned compiled Python files (.pyc
files without an accompanying .py file) have been loaded preferentially by
the presubmit scripts, causing weird problems. This adds a check and a mode for
such files, either warning the user or deleting them.
BUG=None
TEST=local
- Tested against local repository.
R=iannucci@chromium.org, szager@chromium.org
Review URL: https://codereview.chromium.org/621533002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@292703 0039d316-1c4b-4281-b951-d872f2087c98
After switching to a pure git workflow, most of the patchset we upload
to rietveld have git metadata. Apparently, however, the scripts here in
depot tools, which are used by the CQ and trybots, are ignoring that
and applying patches without taking advantage of git metadata.
In practice this causes people to rebase and reupload patches more than
necessary, even in the cases when it could be handled automatically by
means of a three way merge.
This change updates the GitCheckout class of depot_tools to use that.
BUG=416003
Review URL: https://codereview.chromium.org/577203002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@292087 0039d316-1c4b-4281-b951-d872f2087c98
Then this was changed to CheckCallAndFilter it broke
the expectations of code in the buildbot tree:
scripts/slave/chromium_commands.py:extract_revisions
Alternatively we could update the expectations
of chromium_commands.py.
BUG= https://code.google.com/p/chromium/issues/detail?id=412818
Review URL: https://codereview.chromium.org/587253005
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@292072 0039d316-1c4b-4281-b951-d872f2087c98
This reverts commit 931b6c6a6c.
This was causing our try bots to fail on DEPS changes.
After applying the patch successfully, apply_issue.py tries to run gclient sync to get the updated DEPS, resulting in this error:
src (ERROR)
----------------------------------------
[0:00:00] Started.
----------------------------------------
Error:
____ src at origin/master
Your index contains uncommitted changes
Please commit, stash, or reset.
BUG=413326
TESTED=Manually: https://paste.googleplex.com/6375653263802368
Review URL: https://codereview.chromium.org/563873002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@291932 0039d316-1c4b-4281-b951-d872f2087c98
Without --exit-code, diff-index always returns 0 and thus never throws
the exception for a dirty index.
R=iannucci@chromium.org
Review URL: https://codereview.chromium.org/548553003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@291881 0039d316-1c4b-4281-b951-d872f2087c98
This CL prevents map-branches from loading the tracking status when
the -v flag is not supplied. This prevents the vanilla map-branches
from taking a potentially long time to retrieve the tracking status.
BUG=410137
Review URL: https://codereview.chromium.org/536793002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@291846 0039d316-1c4b-4281-b951-d872f2087c98
This CL adds information to the git map-branches command. Invoking
it map-branches with -v, will show tracking status of branches and
invoking with -vv will additionally show the Rietveld URL and the
branch hash.
BUG=None
Review URL: https://codereview.chromium.org/509843002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@291776 0039d316-1c4b-4281-b951-d872f2087c98
This is broken for a few reasons (see bug for details). Also, this works automatically now with the analyze step.
This is a revert of r280039.
BUG=406238
R=iannucci@chromium.org, sky@chromium.org
Review URL: https://codereview.chromium.org/501503002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@291526 0039d316-1c4b-4281-b951-d872f2087c98
shlex.spit(), in addition to doing str.split(' '), also strips out '\\'
from windows paths, which causes the cache_dir check to fail and Gclient to think
that we're not in cache_dir mode even if we are.
Instead of using shlex to strip data from a stdout log, I think regex is more
suited for this job.
BUG=405973
Review URL: https://codereview.chromium.org/497053002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@291446 0039d316-1c4b-4281-b951-d872f2087c98
Some options have words separated by underscores. Added options with
same name and underscores replaced by hyphens.
BUG=400953
Review URL: https://codereview.chromium.org/436963005
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@288366 0039d316-1c4b-4281-b951-d872f2087c98
Original CL: https://codereview.chromium.org/440263002/
Many people* have complained on chromium-dev about the long times
required to perform a full fetch over a DSL. This seems to be mostly
due to the huge size of chromium's history (~9 GB). On the other side,
not everybody is interested in downloading the full git history of
the projects. The size of git packs required to fetch a working HEAD
is one order of magnitude smaller (1.5 GB).
This change makes it possible to perform a shallow fetch (in a way
which is consistent with DEPS, leveraging git templates on clone),
reducing fetch times by 80% for those not interested in the history.
* See:
[chromium-dev] "fetch chromium" keeps hanging/getting stuck on Windows 7
[chromium-dev] Initial checkout with git taking long
[chromium-dev] Trying to get latest source code fails when fetching
[chromium-dev] Gclient sync takes too long
BUG=228996
TBR=iannucci@chromium.org,szager@chromium.org,wtc@chromium.org
Review URL: https://codereview.chromium.org/440273002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@287793 0039d316-1c4b-4281-b951-d872f2087c98
Reason for revert:
Broke the WebRTC waterfall:
http://build.chromium.org/p/tryserver.webrtc/builders/win/builds/3958/steps/gclient%20revert/logs/stdio
Original issue's description:
> Add --no-history option to fetch and gclient for shallow clones.
>
> Many people* have complained on chromium-dev about the long times
> required to perform a full fetch over a DSL. This seems to be mostly
> due to the huge size of chromium's history (~9 GB). On the other side,
> not everybody is interested in downloading the full git history of
> the projects. The size of git packs required to fetch a working HEAD
> is one order of magnitude smaller (1.5 GB).
> This change makes it possible to perform a shallow fetch (in a way
> which is consistent with DEPS, leveraging git templates on clone),
> reducing fetch times by 80% for those not interested in the history.
>
> * See:
> [chromium-dev] "fetch chromium" keeps hanging/getting stuck on Windows 7
> [chromium-dev] Initial checkout with git taking long
> [chromium-dev] Trying to get latest source code fails when fetching
> [chromium-dev] Gclient sync takes too long
>
> BUG=228996
>
> Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=287606
TBR=iannucci@chromium.org,szager@chromium.org,wtc@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=228996
Review URL: https://codereview.chromium.org/440263002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@287637 0039d316-1c4b-4281-b951-d872f2087c98
Many people* have complained on chromium-dev about the long times
required to perform a full fetch over a DSL. This seems to be mostly
due to the huge size of chromium's history (~9 GB). On the other side,
not everybody is interested in downloading the full git history of
the projects. The size of git packs required to fetch a working HEAD
is one order of magnitude smaller (1.5 GB).
This change makes it possible to perform a shallow fetch (in a way
which is consistent with DEPS, leveraging git templates on clone),
reducing fetch times by 80% for those not interested in the history.
* See:
[chromium-dev] "fetch chromium" keeps hanging/getting stuck on Windows 7
[chromium-dev] Initial checkout with git taking long
[chromium-dev] Trying to get latest source code fails when fetching
[chromium-dev] Gclient sync takes too long
BUG=228996
Review URL: https://codereview.chromium.org/437903002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@287606 0039d316-1c4b-4281-b951-d872f2087c98
The user message says the subcommand will stop working on July 1.
BUG=
Review URL: https://codereview.chromium.org/396233002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@285586 0039d316-1c4b-4281-b951-d872f2087c98
It serves no purpose, and it's annoying when the presubmit checks take more than
2-3 seconds because I always switch off to another window, so I come back
minutes later seeing this prompt waiting for me.
R=stip@chromium.org
BUG=
Review URL: https://codereview.chromium.org/407413002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@285071 0039d316-1c4b-4281-b951-d872f2087c98
This will remove a Python 2.7 dependency from the tests.
TBR=agable@chromium.org,iannucci@chromium.org
Review URL: https://codereview.chromium.org/399223002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@283834 0039d316-1c4b-4281-b951-d872f2087c98
Also cast recursedeps to a set. We'll continue
to support using a list literal form in DEPS for
now.
R=iannucci@chromium.org,agable@chromium.org
BUG=393000
Review URL: https://codereview.chromium.org/385123008
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@283474 0039d316-1c4b-4281-b951-d872f2087c98
Created the 'GitRefish' class to centralize 'git' refish parsing and consistent
usage by 'gclient' 'git' code.
BUG=373504
TEST=localtest
R=agable@chromium.org, iannucci@chromium.org
Review URL: https://codereview.chromium.org/328843005
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@281553 0039d316-1c4b-4281-b951-d872f2087c98
Reason for revert:
Breaks WebRTC (and possibly other projects actually using https:// for svn access).
Original issue's description:
> Allow git cl also in repos with read-only git-svn.
>
> If you have read-only git-svn git cl would still try
> to use svn commands, which would then fail. This
> changes git cl to only use git-svn if the remote
> svn repository use the svn:// protocol. It matches
> how chromium works and it allowed me to upload a patch.
>
> BUG=391430
>
> R=iannucci
>
> Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=281500TBR=iannucci@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=391430
Review URL: https://codereview.chromium.org/375553002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@281513 0039d316-1c4b-4281-b951-d872f2087c98
If you have read-only git-svn git cl would still try
to use svn commands, which would then fail. This
changes git cl to only use git-svn if the remote
svn repository use the svn:// protocol. It matches
how chromium works and it allowed me to upload a patch.
BUG=391430
R=iannucci
Review URL: https://codereview.chromium.org/344013005
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@281500 0039d316-1c4b-4281-b951-d872f2087c98
Now that recurselist is no longer a list, it doesn't make
sense to call it recurselist. recurseset is available, but
that's not as easy to read/say compared to recurselist.
Call this recursedeps, instead.
R=iannucci@chromium.org
BUG=390246
Review URL: https://codereview.chromium.org/363103002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@281107 0039d316-1c4b-4281-b951-d872f2087c98
It's possible to tell gclient to use a different
"deps" file from the default DEPS through the "deps_file"
variable in the .gclient file.
If this file is missing, fallback to DEPS (the
default).
BUG=390700
Review URL: https://codereview.chromium.org/368713002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@280921 0039d316-1c4b-4281-b951-d872f2087c98
Previously, recursion overrides were only available by setting
a numeric 'depth' value in a DEPS file. This meant that it
was not possible to control recursion per-dependency entry.
This change adds a recurselist variable with a list structure.
If a named dependency is present in the list, then gclient will
recurse into that dependency's DEPS.
As part of this change, I move the recursion controls off of
DependencySetting and onto Dependency. The new setup of being
based on Dependency allows access to the dependency's name.
The controls are only called from Dependency instances. They
have always needed access to self.parent (in the Dependency
context), so this should be more correct than the previous setup.
BUG=390246
Review URL: https://codereview.chromium.org/331373009
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@280690 0039d316-1c4b-4281-b951-d872f2087c98
Replaced multiple various invocations of 'git fetch' with calls to a common
fetch function.
BUG=373504
TEST=localtest
Review URL: https://codereview.chromium.org/327803006
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@279560 0039d316-1c4b-4281-b951-d872f2087c98
This is an issue when bot_update.py is used, and a top-level
solution takes a long time to fetch. Without this change, it will
be fetched twice.
managed=False really means 'hands off my checkout', so gclient
should honor that.
R=hinoka@chromium.org,agable@chromium.org
BUG=
Review URL: https://codereview.chromium.org/334343002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@277565 0039d316-1c4b-4281-b951-d872f2087c98
Reason for revert:
Speculative revert to see if this is the cause of auto_roll_test.py to fail in build/ presubmit.
Original issue's description:
> scm.GIT.IsValidRevision: Only return True if the given object is a commit
>
> BUG=383476
>
> Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=276487
TBR=iannucci@chromium.org,maruel@chromium.org,borenet@google.com
NOTREECHECKS=true
NOTRY=true
BUG=383476
Review URL: https://codereview.chromium.org/329393002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@276493 0039d316-1c4b-4281-b951-d872f2087c98
raphael.kubo.da.costa@intel.com
primiano@chromium.org
tfarina@chromium.org
sbc@chromium.org
hinoka@chromium.org
scottmg@chromium.org
kjellander@chromium.org
thakis@chromium.org
dnj@chromium.org
pgervais@chromium.org
tandrii@chromium.org
smut@google.com
mmoss@chromium.org
calamity@chromium.org
luqui@chromium.org
rmistry@google.com
jam@chromium.org
hinoka@chromium.org
vadimsh@chromium.org
pgervais@chromium.org
primiano@chromium.org
treib@chromium.org
maruel@chromium.org
cmp@chromium.org
smut@google.com
dnj@chromium.org
bratell@opera.com
martiniss@chromium.org
jrobbins@chromium.org
szager@chromium.org
hinoka@google.com