feat(leanproject mk-cache --force): create a temporary commit to house dirty caches

[eric-wieser]

The cache is indexed by the SHA1 of the working tree that produced it.
Previously mk-cache --force ignored this indexing scheme, replacing the cache for SHA1 with a non-matching cache.

The new behavior is to create a temporary commit containing the changes in the working tree, and associate the cache with that commit.
The commit is not created on the users current branch, so does not interfere with the user's use of git.

Zulip thread

[jcommelin]

Hmm, I still think that users could get mightily confused by this behaviour.

# In a dirty working tree on branch foobar
leanproject mk-cache --force
git checkout master
leanproject get-cache
# do stuff
git checkout foobar
leanproject get-cache # fail because the sha of this revision doesn't match the temporary commit, so no caches were made for this revision

So users have to be very conscious that the should save that sha that is posted back to them. If you run this at 22:37 before you go to bed, and close your terminal, the sha is lost, and only git ref-log magic can retrieve it for you.

[eric-wieser]

I agree; the main argument I have for this behavior is it's less harmful than the current behavior. We could also just remove mk-cache --force entirely.

Regarding reflog magic; we could have a special leancache "ref" (but not branch) such that git reflog leancache shows the history of applied caches.

[jcommelin]

I vote in favour of removing --force. If the directory is dirty, tell the user to clean up the mess. That's the most predictable behaviour.