We have a custom implementation of a Future class as well as some async cache (async_memoizer), which we use for caching data we get from the GitHub API. In the early days of spr development, this was desirable because spr was thought to run on a whole stack of diffs (local branch), and any except the first commit would reference the pull request it corresponds to as well as the pull request it is based on. At that point, we'd need the data for the first pull request for processing both the first and the second commit (the latter would have it as the PR it's based on). The user might also choose different dependencies, having multiple commits be logically based on one PR, so we would require the data on that PR potentially many times. The caching layer solved that in a very general way, never requesting the same data twice.
The concepts in spr have changed a little: stacking on an existing PR is no longer explicitly declared. In all but very unusual cases, we never need to request the same data twice now anyway.
This commit gets rid of the caching, in order to get rid of code complexity we no longer benefit from.
Test Plan:
in my test repo, on a branch with many local commits I have tried spr diff --all, spr amend --all, spr format --all. I then changed the bottom commit of the stack and ran the commands again.
We have a custom implementation of a
Futureclass as well as some async cache (async_memoizer), which we use for caching data we get from the GitHub API. In the early days of spr development, this was desirable because spr was thought to run on a whole stack of diffs (local branch), and any except the first commit would reference the pull request it corresponds to as well as the pull request it is based on. At that point, we'd need the data for the first pull request for processing both the first and the second commit (the latter would have it as the PR it's based on). The user might also choose different dependencies, having multiple commits be logically based on one PR, so we would require the data on that PR potentially many times. The caching layer solved that in a very general way, never requesting the same data twice. The concepts in spr have changed a little: stacking on an existing PR is no longer explicitly declared. In all but very unusual cases, we never need to request the same data twice now anyway. This commit gets rid of the caching, in order to get rid of code complexity we no longer benefit from.Test Plan: in my test repo, on a branch with many local commits I have tried
spr diff --all,spr amend --all,spr format --all. I then changed the bottom commit of the stack and ran the commands again.