aboutsummaryrefslogtreecommitdiff
path: root/doc/design/assumeutxo.md
diff options
context:
space:
mode:
authorglozow <gloriajzhao@gmail.com>2022-09-13 15:37:26 +0100
committerglozow <gloriajzhao@gmail.com>2022-09-13 15:42:18 +0100
commit3a7e0a210c86e3c1750c7e04e3d1d689cf92ddaa (patch)
tree594be180eeafc3cccd0e44f3941a97078228dc59 /doc/design/assumeutxo.md
parent141540a71f510f26e8aa8b551139a978dae2be84 (diff)
parent00eeb31c7660e2c28f189f77a6905dee946ef408 (diff)
downloadbitcoin-3a7e0a210c86e3c1750c7e04e3d1d689cf92ddaa.tar.xz
Merge bitcoin/bitcoin#24513: CChainState -> Chainstate
00eeb31c7660e2c28f189f77a6905dee946ef408 scripted-diff: rename CChainState -> Chainstate (James O'Beirne) Pull request description: Alright alright alright, I know: we hate refactors. We especially hate cosmetic refactors. Nobody knows better than I that changing broad swaths of code out from under our already-abused collaborators, only to send a cascade of rebase bankruptcies, is annoying at best and sadistic at worst. And for a rename! The indignation! But just for a second, imagine yourself. Programming `bitcoin/bitcoin`, on a sandy beach beneath a lapis lazuli sky. You go to type the name of what is probably the most commonly used data structure in the codebase, and you *only hit shift once*. What could you do in such a world? You could do anything. [The only limit is yourself.](https://zombo.com/) --- So maybe you like the idea of this patch but really don't want to deal with rebasing. You're in luck! Here're the commands that will bail you out of rebase bankruptcy: ```sh git rebase -i $(git merge-base HEAD master) \ -x 'sed -i "s/CChainState/Chainstate/g" $(git ls-files | grep -E ".*\.(py|cpp|h)$") && git commit --amend --no-edit' # <commit changed?> git add -u && git rebase --continue ``` --- ~~Anyway I'm not sure how serious I am about this, but I figured it was worth proposing.~~ I have decided I am very serious about this. Maybe we can have nice things every once in a while? ACKs for top commit: MarcoFalke: cr ACK 00eeb31c7660e2c28f189f77a6905dee946ef408 hebasto: ACK 00eeb31c7660e2c28f189f77a6905dee946ef408 glozow: ACK 00eeb31c7660e2c28f189f77a6905dee946ef408, thanks for being the one to propose this w0xlt: ACK https://github.com/bitcoin/bitcoin/pull/24513/commits/00eeb31c7660e2c28f189f77a6905dee946ef408 Tree-SHA512: b828a99780614a9b74f7a9c347ce0687de6f8d75232840f5ffc26e02bbb25a3b1f5f9deabbe44f82ada01459586ee8452a3ee2da05d1b3c48558c8df6f49e1b1
Diffstat (limited to 'doc/design/assumeutxo.md')
-rw-r--r--doc/design/assumeutxo.md4
1 files changed, 2 insertions, 2 deletions
diff --git a/doc/design/assumeutxo.md b/doc/design/assumeutxo.md
index 2726cf779b..c353c78ff8 100644
--- a/doc/design/assumeutxo.md
+++ b/doc/design/assumeutxo.md
@@ -41,7 +41,7 @@ be of use.
Chainstate within the system goes through a number of phases when UTXO snapshots are
used, as managed by `ChainstateManager`. At various points there can be multiple
-`CChainState` objects in existence to facilitate both maintaining the network tip and
+`Chainstate` objects in existence to facilitate both maintaining the network tip and
performing historical validation of the assumed-valid chain.
It is worth noting that though there are multiple separate chainstates, those
@@ -53,7 +53,7 @@ data.
### "Normal" operation via initial block download
-`ChainstateManager` manages a single CChainState object, for which
+`ChainstateManager` manages a single Chainstate object, for which
`m_snapshot_blockhash` is null. This chainstate is (maybe obviously)
considered active. This is the "traditional" mode of operation for bitcoind.