This is in keeping with git's default behavior for other porcelain
commands. It also makes it more tenable for projects to introduce
submodules instead of repo manifests without breaking git-cl upload
and similar tools.
Bug: 958499
Test: Run locally
Change-Id: Id9595271bf89aa8ba928026501a4c9487e5abf8e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1592572
Reviewed-by: Aaron Gable <agable@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Eli Ribble <eliribble@chromium.org>
The scripts still work with Python 2.
There are no intended behaviour changes.
Bug: 939847
Change-Id: Icada60c5b2cf351d62aead26b7364fcef2c2a3e5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1524486
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Raul Tambre <raul@tambre.ee>
This fixes the case where a new workdir is created from a repository
which was previously created with gclient-new-workdir.py and that
repository is later deleted, rendering the symbolic links created by
gclient-new-workdir.py invalid.
It also fixes support_cow() returning 'True' in that case because 'cp
--reflink' does not fail when copying a symlink.
Bug: 721585
Change-Id: I84f4d80b8698af0da346be559d46a328ec0d0e9b
Reviewed-on: https://chromium-review.googlesource.com/842402
Reviewed-by: Aaron Gable <agable@chromium.org>
Commit-Queue: Dirk Pranke <dpranke@chromium.org>
If you have too many bytes of untracked+ignored data in your repo then
gclient sync will fail, confidently telling you how many bytes of this
type you have. The problem is, it lies. It reports the level as soon as
it is exceeded, even though it has not finished totaling up the file
sizes. This change makes the reporting accurate.
I noticed this problem because "gclient sync" told me I had 1049.9 MB
of untracked data. I deleted some and it then said I had 1563.9 MB of
untracked data. Hmmm.
Bug: 376099
Change-Id: I797a4279ad666d83c4a5fbd54bdf7ddbf0e7ad84
Reviewed-on: https://chromium-review.googlesource.com/850854
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Aaron Gable <agable@chromium.org>
Several tools, including the "git" recipe module, hard-code a
checkout-relative "git.bat" path. Git is a feature that is provided by
the system, both to tooling and recipes:
1) For users, "depot_tools" must be on PATH, and during setup it will
have installed "git.bat", ensuring that Git tooling is available in
PATH.
2) For bots, the system is responsible for providing "git.bat" on PATH.
This is typically done at "/b/depot_tools/git.bat", which is sync'd
through the "update_scripts" step.
By formally treating Git as a system resource, we absolve Windows bots
and users from manually installing a depot_tools-local Git, bringing
them in line with other platforms.
BUG=chromium:590806
TEST=local
Change-Id: I93e89855cdd330a2ba7a8cfb8117a1789d1ab54e
Reviewed-on: https://chromium-review.googlesource.com/568694
Commit-Queue: Daniel Jacques <dnj@chromium.org>
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
If the Infra Git wrapper is managing a Git execution, "git_retry" will
impose a second set of retries. Recognize this situation and disable
"git_retry" so that the Git wrapper is the sole managing process.
BUG=chromium:703868
TEST=local
- Ran with and without environment variable, seems to work.
Change-Id: I4f749c9693a761abe2a062ed5f1dc09f51c69e30
Reviewed-on: https://chromium-review.googlesource.com/469229
Commit-Queue: Daniel Jacques <dnj@chromium.org>
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
7-digit hashes are bogus, so I run with core.abbrev = 12.
Non-default settings for core.abbrev caused the git blame test to fail,
because it was hard-coded to look for exactly 7 digits. This change
allows an --abbrev option to be passed to the git-blame wrapper, and
ensures that the same value is used for the git-blame operation and the
computed expectation.
TEST=tests/git_common_test.py GitReadOnlyFunctionsTest.testBlame
Change-Id: I83cbf4dd7267ea36607119bef52f303d59c3f840
Reviewed-on: https://chromium-review.googlesource.com/451124
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Before, for the common case that the actual_merge_base was already set
as base, the check for is_ancestor(base, actual_merge_base) would have
caused the base to be re-set.
This is a writing operation, which causes trouble e.g. for the parallel
operation of 'git cl status'.
R=iannucci@chromium.org, tandrii@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1888213004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@300003 0039d316-1c4b-4281-b951-d872f2087c98
Previously, when a commit was skipped, it would be blamed on the line
number the line had *after* the skipped commit. This could mean a
totally unrelated commit gets blamed. Now, a heuristic analyses the diff
of the skipped commit to discover approximately what line number the
line had *before* the skipped commit, so it can hopefully be blamed on
the right commit.
BUG=574290
Review URL: https://codereview.chromium.org/1629253002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298609 0039d316-1c4b-4281-b951-d872f2087c98
Currently, the script requires you to pass the unwanted commits on the
command line, but eventually, you could configure it with a file
(checked into the repo) that provides a fixed set of commits to always
skip (such as commits that do a huge amount of renaming and nothing
else).
BUG=574290
Review URL: https://codereview.chromium.org/1559943003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298544 0039d316-1c4b-4281-b951-d872f2087c98
Through a comedy of wrapper scripts, the ^ is being swallowed, which
causes the `git config` invocation to match all lines which HAVE
"remote" in them, instead of matching lines which BEGIN with remote.
R=maruel@chromium.org, pkasting@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1566343002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298185 0039d316-1c4b-4281-b951-d872f2087c98
This uses the same trick as git-new-workdir to reuse an existing git
checkout without interfering with it. However, this makes it only usable
on platforms where os.symlink exists.
BUG=404755
Review URL: https://codereview.chromium.org/1342383002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@296920 0039d316-1c4b-4281-b951-d872f2087c98
This prevents `git rebase-update` from losing work when using a hook like
pre-commit-go.
R=dnj@chromium.org, vadimsh@chromium.org, maruel@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1350043002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@296737 0039d316-1c4b-4281-b951-d872f2087c98
It is not clear why it was skipped in r293502, but it was problematic
before that as it can be seen from CL 802403003.
The reason for the different results (and likely the reason why the test
was skipped) is that the handling of the %(upstream:track) and
%(upstream:trackhort) formatting tags was broken in git itself until
version 2.3.0. This was fixed in git commit b6160d95, and the fix shows
that the test expectations in testGetBranchesInfo() were actually wrong
in one of the cases.
Fix the expectations and make sure we only use %(upstream:track) in the
test when a suitable git version is present.
R=pgervais@chromium.org,iannucci@chromium.org
Review URL: https://codereview.chromium.org/1195933003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295814 0039d316-1c4b-4281-b951-d872f2087c98
Otherwise this creates a mess for WIP branches that do not pass the git
pre-commit hook.
R=iannucci@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1179273003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295742 0039d316-1c4b-4281-b951-d872f2087c98
* When aborting a failed rebase, don't cascade errors if the abort itself
fails.
* When starting a rebase-update cycle, cd to the root of the repo. This avoids
an issue when you run rebase-update from inside of a branch which adds a
new folder.
R=agable@chromium.org
BUG=499031
Review URL: https://codereview.chromium.org/1180673003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295637 0039d316-1c4b-4281-b951-d872f2087c98
In git version 2.4 the git branch command prints "* (HEAD detached at"
or "* (HEAD detached from" instead of "* (detached from". Adjust the parsing to make our tests
still work with git 2.4.
BUG=487172
Review URL: https://codereview.chromium.org/1162763003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295578 0039d316-1c4b-4281-b951-d872f2087c98
Error out of the current tree is dirty (previously the dirty
content would be incorporated silently into the newly
squashed branch!).
Review URL: https://codereview.chromium.org/1064933004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@294744 0039d316-1c4b-4281-b951-d872f2087c98
I've run in the exceptions a few times when doing
'git cl presubmit' or 'git cl lint' from a detached
HEAD state (not uncommon when using 'git rebase-update')
Review URL: https://codereview.chromium.org/792933003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293643 0039d316-1c4b-4281-b951-d872f2087c98
Don't discard stderr from failed rebase operations
I had an issue where stdout of the failed rebase was
empty but stderr contained:
First, rewinding head to replay your work on top of it...
Dirty index: cannot apply patches (dirty: internal_gyp
third_party/html_office).
Also, in my case the second rebase was actually succeeding
for some reason, which is clearly no expected, so assert
in this case.
BUG=410339
Review URL: https://codereview.chromium.org/645763002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@292444 0039d316-1c4b-4281-b951-d872f2087c98
This tool can automatically set up the necessary git-svn metadata for our
repos that live in SVN but are mirrored to Chrome.
R=iannucci@chromium.org, tandrii@chromium.org
BUG=418973
Review URL: https://codereview.chromium.org/611253003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@292241 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 allows git_cl.py to be used without adding depot_tools to PATH
BUG=
R=iannucci@chromium.org
Review URL: https://codereview.chromium.org/471413003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@289992 0039d316-1c4b-4281-b951-d872f2087c98
Added the 'git-retry' bootstrap command. This can be used to wrap other 'git'
commands around a fault-tolerant retry wrapper.
BUG=295109
TEST=localtest
R=iannucci@chromium.org, petermayo@chromium.org
Review URL: https://codereview.chromium.org/401673003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@285939 0039d316-1c4b-4281-b951-d872f2087c98
This should let the base marker transparently work with plain-old-git tools
which was the idea in the first place. Specifically `git branch -u` without a
corresponding rebase.
R=agable@chromium.org
BUG=373977
Review URL: https://codereview.chromium.org/288323002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@271112 0039d316-1c4b-4281-b951-d872f2087c98
This is a stopgap to prevent people with >20 local branches from running tools
like 'git rebase-update'. This usually indicates that the user isn't in the
habit of cleaning up old branches, which makes these tools unlikely to be useful
in the current state of their repo anyway.
R=agable@chromium.org
BUG=
Review URL: https://codereview.chromium.org/238213006
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@263978 0039d316-1c4b-4281-b951-d872f2087c98
For some reason .output doesn't throw an AttributeError, but returns None ,
instead. .stdout is the correct attribute.
R=agable@chromium.org
BUG=
Review URL: https://codereview.chromium.org/212493003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@259695 0039d316-1c4b-4281-b951-d872f2087c98
git-rebase-update - ensure all branches are up to date
git-new-branch - create branches
git-rename-branch - rename a branch while preserving parentage relationships
git-reparent-branch - change the parent of a branch, including rebasing it correctly onto that new parent.
git-squash-branch - collapse a branch into a single commit
git-upstream-diff - show the diff between the current branch and it's upstream branch
git-mark-merge-base - explicitly set what you want the above tools to consider the merge-base for the current branch.
R=agable@chromium.org, hinoka@chromium.org, stip@chromium.org, szager@chromium.org
BUG=261738
Review URL: https://codereview.chromium.org/184253003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@259520 0039d316-1c4b-4281-b951-d872f2087c98
Eli Ribble
Raul Tambre
Henrique Ferreiro
Bruce Dawson
Mun Yong Jang
Dan Jacques
Francois Doray
Mark Mentovai
Marc-Antoine Ruel
Alan Cutter
agable
qyearsley
iannucci
Arikon
techtonik
clemensh@chromium.org
mgiuca@chromium.org
scottmg@chromium.org
sammc@chromium.org
raphael.kubo.da.costa@intel.com
tandrii@chromium.org
akuegel@chromium.org
sbc@chromium.org
calamity@chromium.org
techtonik@gmail.com
dnj@chromium.org
iannucci@chromium.org