Commit Graph

12 Commits (cf6a5d2026479506b24d46d0325931330ebf7b78)

Author SHA1 Message Date
sbc@chromium.org 71437c0ba5 git-squash-branch: handle empty squashes
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
10 years ago
loislo@chromium.org 67b59e98dc Speculative fix for build on windows build bots.
The root of problem is a _cache_temp file.
git_cache expected that it is a folder.
So rmtree failed to remove it.

BUG=
TBR= dpranke@chromium.org, enne@chromium.org
NOTRY=true

Review URL: https://codereview.chromium.org/825133002

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293502 0039d316-1c4b-4281-b951-d872f2087c98
10 years ago
calamity@chromium.org 745ffa64a0 Skip tracking status in map-branches when -v flag is not supplied.
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
11 years ago
calamity@chromium.org 9d2c880e98 Give git map-branches extra information behind -v and -vv flags.
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
11 years ago
iannucci@chromium.org 10fbe879aa Make marked merge base invalid when the upstream changes.
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
11 years ago
iannucci@chromium.org 3f23cdf56d Abort git tools if git repo has too many local branches.
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
11 years ago
iannucci@chromium.org edeaa81534 Make mark-merge-base cap the marked merge base at the real merge-base.
R=agable@chromium.org
BUG=

Review URL: https://codereview.chromium.org/212213004

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@259697 0039d316-1c4b-4281-b951-d872f2087c98
11 years ago
iannucci@chromium.org c050a5b2be Add a family of git-commands to assist with the management of multiple CLs/branches.
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
11 years ago
iannucci@chromium.org 97345ebf1a Add git thaw/freeze to depot_tools.
R=agable@chromium.org, hinoka@chromium.org, stip@chromium.org, szager@chromium.org
BUG=261738

Review URL: https://codereview.chromium.org/181043018

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@256778 0039d316-1c4b-4281-b951-d872f2087c98
11 years ago
iannucci@chromium.org 8bc9b5c101 Add git-map and git-map-branches to depot_tools.
git-map: Show your local repo's history in a pseudo-graphical format from the command line.

git-map-branches: Show the topology of all of your branches, and their upstream relationships.

git-nav-upstream: Navigate (checkout) to the upstream branch of the current branch.

git-nav-downstream: Navigate (checkout) to a downstream branch of the current branch. If there's more than one downstream branch, then present a menu to select which one you want.

R=agable@chromium.org, hinoka@chromium.org, stip@chromium.org, szager@chromium.org
BUG=

Review URL: https://codereview.chromium.org/184113002

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@256384 0039d316-1c4b-4281-b951-d872f2087c98
11 years ago
bratell@opera.com 0ee42a68c1 Avoid windows presubmit hang in gclient tests.
If os.kill(os.getpid(), signal.CTRL_C_EVENT) doesn't do what the
test author hopes it will do, the test will hang until it has calculated
a million out-of-thread/process results. That is approximately an
infinite hang.

BUG=

Review URL: https://codereview.chromium.org/110883004

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@240319 0039d316-1c4b-4281-b951-d872f2087c98
11 years ago
iannucci@chromium.org aa74cf65d0 Add git-number script to calculate generation numbers for commits.
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
11 years ago