CMDupdate and CMDsync have different option parsers, which means they pass
different options objects to the same underlying code!
R=agable@chromium.org, dnj@chromium.org, smut@chromium.org
BUG=601564
Review URL: https://codereview.chromium.org/1869593004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@299777 0039d316-1c4b-4281-b951-d872f2087c98
This will clean up index.lock and refs/heads/master.lock-style locks when
invoked as part of the update_scripts step on the bots.
R=dpranke@chromium.org, estaab@chromium.org, pgervais@chromium.org
BUG=421769
Review URL: https://codereview.chromium.org/1862943002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@299737 0039d316-1c4b-4281-b951-d872f2087c98
* `git bash` helper now will either:
* launch an interactive bash prompt in the MinGW Terminal Emulator
* launch a non-interactive bash shell if arguments are provided
* `git bash` now includes python, python/Scripts and svn binaries in
the PATH.
* depot_tools' colorization now works in MinGW Terminal Emulator
* batch scripts are now regenerated if any of them is missing.
R=agable@chromium.org, dnj@chromium.org, mmoss@chromium.org
BUG=598956
Review URL: https://codereview.chromium.org/1847783002 .
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@299616 0039d316-1c4b-4281-b951-d872f2087c98
gclient-sync + git-cache are racy because if two different DEPS files
dependent on the same repo URL, even if depsed to different checkout
dirs, they use same git cache dir. If both checkout dirs are synced at
the same time, one of them cannot acquire a lock.
This is a cheap solution to change --lock_timeout option default value
from 0 to 5m.
R=hinoka@chromium.org
BUG=593468
Review URL: https://codereview.chromium.org/1785083005
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@299386 0039d316-1c4b-4281-b951-d872f2087c98
I guess I'm the only developer using git-cache, which is sad.
Hopefully these fixes will make it easier to adapt this to developer
usage some time in the FUTURE.
BUG=583420
TEST=Works for me
R=agable@chromium.org,tandrii@chromium.org
Review URL: https://codereview.chromium.org/1650993005
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298531 0039d316-1c4b-4281-b951-d872f2087c98
Reason for revert:
breaks git-bash on windows
Original issue's description:
> git_cl/gclient: use python2
>
> Newer distros are defaulting /usr/bin/python to python3, so use python2
> explicitly so we continue working.
>
> Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=297535
TBR=stip@chromium.org,sergeyberezin@chromium.org,vapier@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1442583004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297544 0039d316-1c4b-4281-b951-d872f2087c98
Newer distros are defaulting /usr/bin/python to python3, so use python2
explicitly so we continue working.
Review URL: https://codereview.chromium.org/1437773002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297535 0039d316-1c4b-4281-b951-d872f2087c98
The newer form works with python2 and python3.
Review URL: https://codereview.chromium.org/1436763002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297517 0039d316-1c4b-4281-b951-d872f2087c98
This makes the code work both in python2 and python3.
Review URL: https://codereview.chromium.org/1433153003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297516 0039d316-1c4b-4281-b951-d872f2087c98
This helps prevent behavior such as setting '--name .' so that the .gclient
file contains '.' as the name of the solution, and the .gclient file ends
up a sibling of the .git file, rather than a sibling of the git checkout's
containing directory.
R=iannucci@chromium.org, thestig@chromium.org
Review URL: https://codereview.chromium.org/1406053003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297343 0039d316-1c4b-4281-b951-d872f2087c98
This cl ensures that gclient enforces sane revision overrides and
onfiguration when running a revert, just like it does on a normal sync/update.
R=iannucci@chromium.org
BUG=420919
Review URL: https://codereview.chromium.org/1160113003.
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295571 0039d316-1c4b-4281-b951-d872f2087c98
Handle KeyboardInterrupt gracefully rather the printing a
backtrace. Most users of these tools don't expect a
backtrace when then hit Ctrl-C.
Also, fix a few other inconsistencies found in the python
startup code of these different scripts:
- always call main function 'main' (rather than 'Main')
- always return 0 from main function
- if main takes args never include argv[0]
Review URL: https://codereview.chromium.org/955993006
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@294250 0039d316-1c4b-4281-b951-d872f2087c98
This adds the '--auto_rebase' sync option, enabling parallel updates to
automatically rebase local Git branches during sync.
BUG=None
TEST=local
Review URL: https://codereview.chromium.org/930693002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@294151 0039d316-1c4b-4281-b951-d872f2087c98
Reland crrev.com/743083002, which was reverted in crrev.com/796053002
due to some test flakiness, probably related with an old version of Git on
the bots. Relanding now that the infra has been updated to Trusty (plus
adding some de-flake precautions).
Original CL 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
Review URL: https://codereview.chromium.org/910913003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@294082 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
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 breaking the ability to specify an alternate DEPS file, and do
things like sync release tags where DEPS is still from svn and we need
.DEPS.git to do a git checkout.
R=iannucci@chromium.org, szager@chromium.org
BUG=407049
Review URL: https://codereview.chromium.org/511533003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@291665 0039d316-1c4b-4281-b951-d872f2087c98
This is primarily a hack to enable the chromeos ebuild.
BUG=367027
TBR=iannucci@chromium.org,mmoss@chromium.org
Review URL: https://codereview.chromium.org/490233003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@291075 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
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
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
iannucci@chromium.org
smut@google.com
rwalker@codeaurora.org
nodir@chromium.org
sergiyb@chromium.org
tandrii@chromium.org
thakis@chromium.org
szager@chromium.org
vapier@chromium.org
agable@chromium.org
stip@chromium.org
e.hakkinen@samsung.com
sbc@chromium.org
dnj@chromium.org
primiano@chromium.org
mmoss@chromium.org
iannucci@chromium.org
szager@chromium.org
dyen@chromium.org
primiano@chromium.org
cmp@chromium.org
smut@google.com
dnj@chromium.org