You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, neovim deploy assumes that any changes to the staging dir come from the head commit. But if there is a race and two commits come in at nearly the same time due to merge queue, we could attribute the changes to the wrong commit
With cursorless-talon it works well because we use a subtree split, but we can't do that here because deploy is not simply a subtree: we actually build something
I'm not sure exactly the best way to do this. One way would be to keep a staging branch of some sort similar to how we do for cursorless-talon, and then re-build and create the staging directory for every commit between last deployed and head. I still think this might result in a race. We should really try to ensure determinism: the commit history on monorepo main completely determines the commit history on deploy branch
The text was updated successfully, but these errors were encountered:
Today, neovim deploy assumes that any changes to the staging dir come from the head commit. But if there is a race and two commits come in at nearly the same time due to merge queue, we could attribute the changes to the wrong commit
With cursorless-talon it works well because we use a subtree split, but we can't do that here because deploy is not simply a subtree: we actually build something
I'm not sure exactly the best way to do this. One way would be to keep a staging branch of some sort similar to how we do for cursorless-talon, and then re-build and create the staging directory for every commit between last deployed and head. I still think this might result in a race. We should really try to ensure determinism: the commit history on monorepo main completely determines the commit history on deploy branch
The text was updated successfully, but these errors were encountered: