In theory this should prevent `git rebase-update` from invoking
potentially expensive `git gc` operations after every `git rebase`
(ideally once per branch, but sometimes as many as three per branch (!)).
This has outsized effects as the size of the repo or number of branches
increases, and additionally has penalties on Windows due to git's
POSIXey assumptions around how disk I/O works.
After doing all rebase stuff, we run `git gc --auto` from rebase-update
once (assuming we were successful; if the command failed then we don't
run gc at all).
R=apolito@google.com
Bug: 617218
Change-Id: I37a8f7953779f15b320e4ed7bb85119cb4bb665a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2868766
Auto-Submit: Robbie Iannucci <iannucci@chromium.org>
Reviewed-by: Anthony Polito <apolito@google.com>
Commit-Queue: Robbie Iannucci <iannucci@chromium.org>
If origin/HEAD resolves to `master`, depot_tools can check if
origin/main exists. If so, it's very likely that origin/HEAD should be
updated to point to origin/main.
In the worst case, this will result in extra git remote call while not
changing local state (i.e origin/HEAD remained unchanged).
R=gavinmak@google.com
Bug: 1190702
Change-Id: I51e69d7a95d3534e1820099b4b6983d38b5e2763
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2795075
Reviewed-by: Gavin Mak <gavinmak@google.com>
Commit-Queue: Josip Sokcevic <sokcevic@google.com>
This change makes git map-branches a little bit faster by avoiding
fetching the revision list of each branch if git map-branches will not
show the tracking info anyway.
Change-Id: I47458871f904004f910aadd7d774bea5193c979e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2695393
Reviewed-by: Anthony Polito <apolito@google.com>
Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
subprocess.DEVNULL was introduced in Python3 to serve same purpose
as subprocess2.VOID, so rename VOID to DEVNULL in subprocess2.
Change-Id: I6dade3306ffc3bc2441ac6083f362b099c2427e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2587758
Reviewed-by: Anthony Polito <apolito@google.com>
Commit-Queue: Edward Lesmes <ehmaldonado@chromium.org>
Using --fork-point when possible reduces the number of merge conflicts when running merge-base.
Bug: 1111269
Change-Id: I7240fdc9a613d2eb4e856b5677fc713551d7afe9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2519729
Reviewed-by: Josip Sokcevic <sokcevic@google.com>
Commit-Queue: Gavin Mak <gavinmak@google.com>
If there is a branch named after a file in the repository root, the
command `git rev-list --count $branch ^$base` is ambiguous. This is
because `git` does not know whether $branch needs to be parsed as a
revision or a filename.
Adding a trailing `--` parameter to the command-line resolves this
ambiguity since when present, everything before the `--` cannot be
a filename and everything after `--` has to one.
From git documentation:
Paths may need to be prefixed with -- to separate them from
options or the revision range, when confusion arises.
Bug: none
Change-Id: Ieb10aa8701e12fc3c88d5f75ff624f61ee8d8aaa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2475773
Reviewed-by: Josip Sokcevic <sokcevic@google.com>
Commit-Queue: Sylvain Defresne <sdefresne@chromium.org>
Currently, for a given branch, map-branches displays the number of
commits ahead and behind it is. This change replaces ahead with
commits, representing the number of commits a branch has, starting from
its base commit, and more accurately reflects the state of a repo.
Bug:1128716
Change-Id: I7c070b4efd452d82d878e1cfb7c20d1c80f38ec7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2412991
Commit-Queue: Gavin Mak <gavinmak@google.com>
Reviewed-by: Josip Sokcevic <sokcevic@google.com>
When source repo is a 'shallow clone', `.git/shallow` is not linked to
the new workdir. Which makes running git command fails in new workdir.
Change-Id: I81d38b7b2cccc482711dcc1dd02ea06fbd01a56d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2211635
Reviewed-by: Aaron Gable <agable@chromium.org>
Commit-Queue: Richard He <linyhe@microsoft.com>
Reverted commit 4511b131e6 had a bug where
squash_ret.success = True and empty_rebase = False. In that case, stdout
and stderr would already be string and trying to decode would fail.
Bug: 1071280
Change-Id: Iadcc526147ebb98aa7a91a7daa64ef44066e83b6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2163387
Commit-Queue: Edward Lesmes <ehmaldonado@chromium.org>
Auto-Submit: Josip Sokcevic <sokcevic@google.com>
Reviewed-by: Edward Lesmes <ehmaldonado@chromium.org>
Fixed by switching "stat()" to "lstat()".
Does not seem to be a python3 vs python2 thing (fails on py2 as well).
Bug: 1071066
Change-Id: I7eea9ed39b43e09ae2f7558bf23c12581f02e4a2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2150507
Reviewed-by: Edward Lesmes <ehmaldonado@chromium.org>
Commit-Queue: Edward Lesmes <ehmaldonado@chromium.org>
Auto-Submit: Andrew Grieve <agrieve@chromium.org>
This was made by running `codespell` and `scspell`
and then checking the results.
Change-Id: I169fd5b40294f83015075b4a899fbca263821f25
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2144602
Commit-Queue: Quinten Yearsley <qyearsley@chromium.org>
Auto-Submit: Quinten Yearsley <qyearsley@chromium.org>
Reviewed-by: Edward Lesmes <ehmaldonado@chromium.org>
This fixes default value for Windows platform. Unit tests still don't
work for Windows as CTRL+C handling is not working properly.
Change-Id: I11fd33279313bfd7a2070e90164da6cf9f63696e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2121555
Commit-Queue: Josip Sokcevic <sokcevic@google.com>
Reviewed-by: Edward Lesmes <ehmaldonado@chromium.org>
Remove default value from optional arguments, since they are always passed.
In particular, the default value for `out` was a text stream (sys.stdout),
but the value passed to `out` is always a binary stream, which is confusing.
Get rid of the `err` argument, since it is always sys.stderr, and only used
for testing.
Change-Id: Ia289e9a97b968a0c802fc2f419397c1e494f713c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1986064
Reviewed-by: Anthony Polito <apolito@google.com>
Commit-Queue: Edward Lesmes <ehmaldonado@chromium.org>
Auto-Submit: Edward Lesmes <ehmaldonado@chromium.org>
git hyper_blame might use a subprocess' stdin for its stdout,
which is opened to accept byte input.
The text must be encoded before printing to stdout to avoid
unicode errors.
Bug: 1028709
Change-Id: If2a270a7f3f69a818d367616f6732245de364db9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1937500
Reviewed-by: Andy Perelson <ajp@chromium.org>
Commit-Queue: Edward Lesmes <ehmaldonado@chromium.org>
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
Robert Iannucci
Josip Sokcevic
Antonio Sartori
Edward Lesmes
Gavin Mak
Sylvain Defresne
Richard He
Andrew Grieve
Quinten Yearsley
Jeffrey Yasskin
Edward Lemur
Eli Ribble
Raul Tambre
Henrique Ferreiro
Bruce Dawson
Mun Yong Jang
Dan Jacques
Francois Doray
Mark Mentovai
Marc-Antoine Ruel
Alan Cutter
agable
Arikon
techtonik
clemensh@chromium.org
mgiuca@chromium.org
scottmg@chromium.org
sammc@chromium.org
raphael.kubo.da.costa@intel.com