Follow up to crrev.com/c/2125626.
This allows depot_tools commands to run successfully when depot_tools is
installed in a path containing spaces.
Change-Id: I8f99dbdcb3b1acf27d51ce26b6153f643b8d4dcd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2127675
Commit-Queue: Edward Lesmes <ehmaldonado@chromium.org>
Reviewed-by: Josip Sokcevic <sokcevic@google.com>
Retrying the change in https://codereview.chromium.org/1415993003/, with
fixes to properly handle being called with either Windows- or
POSIX-style paths (the previous attempt assumed it was always called
with POSIX-style paths under MSYS, which itself was attempting to fix
the assumption that it was always called with Windows-style paths, but
neither assumption was right).
This change doesn't actually use the wrapper in any new places, but
subsequent changes will be made to use it in places where
'exec python' is called directly, like gclient and fetch.
BUG=411518
R=iannucci@google.com, sky@google.com
Review URL: https://codereview.chromium.org/1411793006
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297401 0039d316-1c4b-4281-b951-d872f2087c98
Reason for revert:
Speculative revert in case this caused the bots to fail bot_update.
Original issue's description:
> Generalize python_git_runner for use in non-git scripts.
>
> Also fixes an msys (git-bash) incompatibility, similar to the one
> fixed in crrev.com/4845f0ed694ff071da5f6ee937a0bce2ea4e6fd2.
>
> This change doesn't actually use the wrapper in any new places, but
> subsequent changes will be made to use it in places where
> 'exec python' is called directly, like gclient and fetch.
>
> BUG=411518
> R=iannucci@google.com
>
> Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=297357
TBR=iannucci@google.com,iannucci@chromium.org,mmoss@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=411518
Review URL: https://codereview.chromium.org/1414923008
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297358 0039d316-1c4b-4281-b951-d872f2087c98
Also fixes an msys (git-bash) incompatibility, similar to the one
fixed in crrev.com/4845f0ed694ff071da5f6ee937a0bce2ea4e6fd2.
This change doesn't actually use the wrapper in any new places, but
subsequent changes will be made to use it in places where
'exec python' is called directly, like gclient and fetch.
BUG=411518
R=iannucci@google.com
Review URL: https://codereview.chromium.org/1415993003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297357 0039d316-1c4b-4281-b951-d872f2087c98
This introduces python_git_runner.sh, and makes git-cl, git-cache, git-number,
and git-try use it.
R=agable@chromium.org, szager@chromium.org
BUG=261738
Review URL: https://codereview.chromium.org/188383002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@256131 0039d316-1c4b-4281-b951-d872f2087c98
Compatible with any git topology (multiple roots, weird branching/merging, etc.)
I can't get it to be any faster (in python). Suggestions welcome :).
On z600/linux, this takes 5.1s to calculate the initial count for 2e3de954ef0a
(HEAD on src.git at the time of writing). Subsequent lookups take ~0.06s. For
reference, this machine takes 3s to just list the revisions in sorted order
without any additional processing (using rev-list).
All calculations are stored in a git-notes-style ref with the exception that the
leaf 'tree' object which would normally be stored in a git-notes world is
replaced with a packed binary file which consists of records [hash int]. Each
run of this script will create only 1 commit object on this internal ref which
will have as its parents:
* The previous git number commit
* All of the target commits we calculated numbers for.
This ref is then excluded on subsequent invocations of rev-list, which means that
git-number will only ever process commit objects which it hasn't already
calculated a value for. It also prevents you from attempting to number this
special ref :).
This implementation only has a 1-byte fanout which seems to be the best
performance for the repos we're dealing with (i.e. on the order of 500k commit
objects). Bumping this up to a 2-byte fanout became extremely slow (I suspect
the internal caching structures I'm using are not efficient in this mode and
could be improved). Using no fanout is slower than the 1 byte fanout for lookups
by about 30%.
R=agable@chromium.org, stip@chromium.org, szager@chromium.org
BUG=280154,309692,skia:1639
Review URL: https://codereview.chromium.org/26109002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@236035 0039d316-1c4b-4281-b951-d872f2087c98
Edward Lesmes
mmoss@chromium.org
akuegel@chromium.org
agable@chromium.org
r.c.ladan@gmail.com
iannucci@chromium.org