diff options
author | George Burgess IV <gbiv@google.com> | 2019-11-08 15:13:19 -0800 |
---|---|---|
committer | George Burgess <gbiv@chromium.org> | 2019-11-20 18:39:07 +0000 |
commit | 55f4933ede7a2b87e759e879b93b73a4570444e6 (patch) | |
tree | 05930c1068982361819121850638677516511c67 /cros_login.py | |
parent | a1c0899146a516acf1134505db0a44a2596aeee7 (diff) | |
download | toolchain-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 'cros_login.py')
0 files changed, 0 insertions, 0 deletions