Consider making `auto-merge` independent of the current branch after initial invocation

[happycollision]

I'd really like to git jaspr auto-merge and then start working on a different branch. Just let that thing cook in the background.

[MichaelSims]

I'd have to clone the working copy into a temporary directory to support this, which might be kind of expensive to do unconditionally. But I will revisit the idea

[MichaelSims]

Note to self: if I'm going to clone into a temp dir, I need to do the shallowest clone I can as this could be very expensive otherwise

[MichaelSims]

There is a way you can do this, but I'd still classify it as "at your own risk":

1. Supply a stable refspec instead of using the default HEAD (which is updated each time you do a checkout/commit/etc.). For example: git jaspr auto-merge origin short-sha:main
2. In another terminal, continue your work... make new commits, switch branches.
3. The auto-merge should not be impacted as long as the stable refspec you provided truly is stable (i.e. doesn't get gc'ed in the middle of the auto-merge)

I'd still say "at your own risk" because I'm fairly certain that the git CLI doesn't support concurrent operations... i.e. when committing or switching branches, it may still be possible to run into a conflict where one git process is blocked by another one holding a lock. auto-merge definitely would not handle that gracefully currently.

FWIW I have tried this workaround once and it worked fine... but again, see the above paragraph.

[happycollision]

Oh that’s interesting. I bet that’d satisfy my desires just fine. I’m also toying more with worktrees these days, which would also work just fine.