DO NOT MERGE THIS IS JUST A TEST - WIP: Switch from stored cached state to computed state #231
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The intention of this change is to fundamentally change gps so that it no longer stores, and manages, local cache about things. Instead it should now simply read the Git tree and compute state from that. This should give us a lot more stability, and remove any brittleness that existed between users switching back and forth between Git Patch Stack commands and classic Git commands. It should also have the benefit of allowing us to expose branches associated with patches in a way to users that can help formalize the concept of a series of patches and bring it forth as a first class citizen. It will have some impacts. For example we will no longer be able to internally have and represent the state of if a patch has had a review requested. This is actually good in my mind as it was state that is actually owned by GitHub/Bitbucket/GitLab and we were simply cacheing it before. To address this in the new world order it using a hook as part of the list command seems like a reasonable way to possibly get that additional state information from its actual source of truth, GitHub/Bitbucket/GitLab. This means we will also lose the ability to know if we are re-requesting review of a patch within the hooks. So the hooks will have to take identifying that from the source of truth on as part of their task. We will also lose the ability know how patches changed since an operation. For example previously we tracked the hash of a patches diff when we performed an operation like syncing it to a remote. This enabled us to determine if the patch was locally changed since the last sync, remotely changed since the last sync, or both. We will no longer have this state. Therefore all we will be able to determine is if the remote patch and the local patch match or don't match. This is something that we will just have to do without. But, I think it is worth the loss to gain the stability and the formal patch series concept. <!-- ps-id: be9e5f1f-75a7-4fce-8f8c-60c2a5d2254e -->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The intention of this change is to fundamentally change gps so that it no longer stores, and manages, local cache about things. Instead it should now simply read the Git tree and compute state from that.
This should give us a lot more stability, and remove any brittleness that existed between users switching back and forth between Git Patch Stack commands and classic Git commands.
It should also have the benefit of allowing us to expose branches associated with patches in a way to users that can help formalize the concept of a series of patches and bring it forth as a first class citizen.
It will have some impacts. For example we will no longer be able to internally have and represent the state of if a patch has had a review requested. This is actually good in my mind as it was state that is actually owned by GitHub/Bitbucket/GitLab and we were simply cacheing it before. To address this in the new world order it using a hook as part of the list command seems like a reasonable way to possibly get that additional state information from its actual source of truth, GitHub/Bitbucket/GitLab.
This means we will also lose the ability to know if we are re-requesting review of a patch within the hooks. So the hooks will have to take identifying that from the source of truth on as part of their task.
We will also lose the ability know how patches changed since an operation. For example previously we tracked the hash of a patches diff when we performed an operation like syncing it to a remote. This enabled us to determine if the patch was locally changed since the last sync, remotely changed since the last sync, or both. We will no longer have this state. Therefore all we will be able to determine is if the remote patch and the local patch match or don't match. This is something that we will just have to do without. But, I think it is worth the loss to gain the stability and the formal patch series concept.