aboutsummaryrefslogtreecommitdiff
path: root/setup_chromeos.py
diff options
context:
space:
mode:
authorGeorge Burgess IV <gbiv@google.com>2019-11-08 15:13:19 -0800
committerGeorge Burgess <gbiv@chromium.org>2019-11-20 18:39:07 +0000
commit55f4933ede7a2b87e759e879b93b73a4570444e6 (patch)
tree05930c1068982361819121850638677516511c67 /setup_chromeos.py
parenta1c0899146a516acf1134505db0a44a2596aeee7 (diff)
downloadtoolchain-utils-55f4933ede7a2b87e759e879b93b73a4570444e6.tar.gz
Add a git-llvm-rev tool
The main down-side to this is sort of inherent in any git-based numbering scheme: as time goes on, our distance from r375505 is going to increase, so any tool that takes this approach will take progressively longer. To get an idea of what that means in practice, I set `base_llvm_revision = 199999` (from 2014) and messed around. Converting a near-ToT SHA to a rev took 250ms, and converting that rev back into a SHA took 191ms. For reference, at their current settings, they take 83ms and 106ms to perform those same options, respectively. Hence, I doubt this will become a problem in the next 5 years. If it does start to bite us, we can add complexity to bound our searches. The only op known to take quite a while on this is converting a branch-only commit to a rev, because `git branch -r --contains ${X}` takes quite a while. I don't think that's a common op, so we can worry about that later. BUG=None TEST=A few random commits round-tripped. Tests passed. `mypy --strict` was happy. Change-Id: If093f3593a9f1aa3c6275d9dcd2785864dbfce1d Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/toolchain-utils/+/1907408 Tested-by: George Burgess <gbiv@chromium.org> Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Diffstat (limited to 'setup_chromeos.py')
0 files changed, 0 insertions, 0 deletions