Make isolation verification not change working tree

[drewdeponte]

The thinking is that this would be possible maybe by using git archive to get a snapshot of the code after successfully cherry-picking the patch in the background. This snapshot could be stored in some temp folder where the isolation verification process could be.

This would make it so people could keep working on what they were while they are also having isolation verification occur. This could be valuable as test suites grow, etc.

[drewdeponte]

@Alizter suggested the other day that we could maybe use git worktrees to do this somehow, https://git-scm.com/docs/git-worktree.

[alondahari]

Great suggestion @Alizter! I'm going to look into this next, unless you have reservations about this @drewdeponte

[drewdeponte]

It is also worth mentioning here that I did implement a spike of this prior to the latest major release. It had various implications and impacts. The only route I really found was to snapshot and use a temp directory. I did NOT explore work trees. But hopefully this will give you some things to think about as exploring.

• because the build process was happening from a fresh archive, it would take longer because there is no build cache
• I forget exactly which hook, maybe isolate_post_cleanup or integrate_post_push, that we ran into state issues with, with some of our implemented hooks (I think it was the code coverage stuff, that it somehow broke)

This did however free up the local environment so that you could continue working why an isolation verification was off running. I guess another thing to consider from a user experience standpoint is that this needs to now be async.

So the user needs to likely poll the status of it as it takes some time. We just removed all of the state tracking out of Git Patch Stack. So we would have to be very confident that introducing state tracking like this wouldn't need to be synchronized across repos, or any other cases like that.

[alondahari]

Thanks for there info. I intend to explore the work tree route, which seems similar to your snapshot implementation on a high level.

I don't see why we would need it to be asynchronous or introduce state. The way I see it, we would (talking gps rr as an example):

• start by creating the rr branch, but not check it out.
• add the work tree and move into it.
• perform the necessary hooks.
• have the same outcome as the current flow, so at the successful end the ps id is added and a message to open a PR on GitHub (or run more hooks if configured).
• do some clean up.

So the end user should not be affected by the change, other than remaining on the main branch and the ability to keep working. Unless I'm missing something?

For your other points:

• we could potentially pass the new work tree path to the hooks so the user can copy any cache into it if they want to before building
• I'll make sure to hit you up for more details on that before integrating a solution.